[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 draft-ietf-pce-pcep-extension-for-pce-controller

PCE Working Group                                           Quintin Zhao
Internet-Draft                                            Katherine Zhao
Intended status: Standards Track                                Robin Li
Expires: Auguest 5, 2014                                     Dhruv Dhody
                                                     Huawei Technologies
                                                             Boris Zhang
                                                              Telus Ltd.
                                                                Feb 2014


   PCEP Procedures and Protocol Extensions for Using PCE as a Central
                       Controller (PCECC) of LSPs
     draft-zhao-pce-pcep-extension-for-pce-controller-00

Abstract

   In certain networks deployment scenarios, service providers would
   like to keep all the existing MPLS functionalities in both MPLS and
   GMPLS while removing the complexity of existing signaling protocols
   such as LDP and RSVP-TE.  In
   [I-D.draft-zhao-pce-central-controller-user-cases], we propose to use
   the PCE as a central controller so that LSP can be calculated/
   signaled/initiated and label forwarding entries are downloaded
   through a centralized PCE server to each network devices along the
   LSP path while leveraging the existing PCE technologies as much as
   possible.

   This draft specify the procedures and PCEP protocol extensions for
   using the PCE as the central controller and user cases where LSPs are
   calculated/setup/initiated and label forwarding entries are
   downloaded through extending the existing PCE architectures and PCEP.

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

   This Internet-Draft will expire on August 5, 2014.



Zhao, et al.               Expires August 5, 2014                  [Page 1]


Internet-Draft                    PCECC                    November 2013


Copyright Notice

   Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  PCEP Requirements  . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Procedures for Using the PCE as the Central Controller
       (PCECC)  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Procedure-1 for PCECC Capability Advertisement . . . . . .  7
     4.2.  Procedure-2 for PCECC's Label Resource Reservations  . . .  8
     4.3.  Procedure-3 for PCECC for LSP Setup in the New PCECC
           Enabled Network  . . . . . . . . . . . . . . . . . . . . .  9
     4.4.  Procedure-4 for PCECC for LSP Setup in the Network
           Migration  . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.5.  Procedure-5 for Using Extended PCEP to download LSP
           information for Each Network Device  . . . . . . . . . . . 10
   5.  PCEP Extensions  . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  New Messages . . . . . . . . . . . . . . . . . . . . . . . 11
       5.1.1.  PCEP Extension for Label Range Reservation Request . . 12
       5.1.2.  PCEP Extension for Label Range reservation Notify  . . 13
       5.1.3.  The LSP Setup Request Message  . . . . . . . . . . . . 14
       5.1.4.  The LSP Delete Request Message . . . . . . . . . . . . 14
       5.1.5.  PCEP Extension for LFIB Entry Downloading  . . . . . . 15
       5.1.6.  PCEP Extension for LFIB Entry Cleanup  . . . . . . . . 16
       5.1.7.  The PCErr Message  . . . . . . . . . . . . . . . . . . 17
     5.2.  Object Formats . . . . . . . . . . . . . . . . . . . . . . 17
       5.2.1.  OPEN Object  . . . . . . . . . . . . . . . . . . . . . 17
         5.2.1.1.  PCECC Capability TLV . . . . . . . . . . . . . . . 17
       5.2.2.  SRQ Object . . . . . . . . . . . . . . . . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   7.  Manageability Considerations . . . . . . . . . . . . . . . . . 18
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18



Zhao, et al.               Expires August 5, 2014                  [Page 2]


Internet-Draft                    PCECC                    November 2013


     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18

















































Zhao, et al.               Expires August 5, 2014                  [Page 3]


Internet-Draft                    PCECC                    November 2013


1.  Introduction

   In certain network deployment scenarios, service providers would like
   to have the ability to dynamically adapt to a wide range of
   customer's requests for the sake of flexible network service
   delivery, Software Defined Networks (SDN)has provides additional
   flexibility in how the network is operated compared to the
   traditional network.

   The existing networking ecosystem has become awfully complex and
   highly demanding in terms of robustness, performance, scalability,
   flexibility, agility, etc.  By migrating to the SDN enabled network
   from the existing network, service providers and network operators
   must have a solution which they can evolve easily from the existing
   network into the SDN enabled network while keeping the network
   services remain scalable, guarantee robustness and availability etc.

   Taking the smooth transition between traditional network and the new
   SDN enabled network into account, especially from a cost impact
   assessment perspective, using the existing PCE components from the
   current network to function as the central controller of the SDN
   network is one choice, which not only achieves the goal of having a
   centralized controller, but also leverages the existing PCE network
   components.

   The Path Computation Element communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform route
   computations in response to Path Computation Clients (PCCs) requests.
   PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
   draft [I-D. draft-ietf-pce- stateful-pce] describes a set of
   extensions to PCEP to enable active control of MPLS-TE and GMPLS
   tunnels.

   [I-D. draft-ietf-pce-pce-initiated-lsp] describes the setup and
   teardown of PCE-initiated LSPs under the active stateful PCE model,
   without the need for local configuration on the PCC, thus allowing
   for a dynamic MPLS network that is centrally controlled and deployed.

   [I-D.draft-ali-pce-remote-initiated-gmpls-lsp-01] complements [I-D.
   draft-ietf-pce-pce-initiated-lsp] by addressing the requirements for
   remote-initiated GMPLS LSPs.

   Segment Routing (SR) technology leverages the source routing and
   tunneling paradigms.  A source node can choose a path without relying
   on hop-by-hop signaling protocols such as LDP or RSVP-TE.  Each path
   is specified as a set of "segments" advertised by link-state routing
   protocols (IS-IS or OSPF).  [I-D.filsfils-rtgwg-segment-routing]
   provides an introduction to SR technology.  The corresponding IS-IS



Zhao, et al.               Expires August 5, 2014                  [Page 4]


Internet-Draft                    PCECC                    November 2013


   and OSPF extensions are specified in [I-D.previdi-isis-segment-
   routing-extensions] and [I-D.psenak-ospf-segment-routing-extensions],
   respectively.

   A Segment Routed path (SR path) can be derived from an IGP Shortest
   Path Tree (SPT).  Segment Routed Traffic Engineering paths (SR-TE
   paths) may not follow IGP SPT.  Such paths may be chosen by a
   suitable network planning tool and provisioned on the source node of
   the SR-TE path.

   It is possible to use a stateful PCE for computing one or more SR-TE
   paths taking into account various constraints and objective
   functions.  Once a path is chosen, the stateful PCE can instantiate
   an SR-TE path on a PCC using PCEP extensions specified in [I-D.ietf-
   pce-pce-initiated-lsp] using the SR specific PCEP extensions
   described in [I-D.draft-sivabalan-pce-segment-routing].

   By using the solutions provided from above drafts, LSP in both MPLS
   and GMPLS network can be setup/delete/maintained/synchronized through
   a centrally controlled dynamic MPLS network.  Since in these
   solutions, either the LSP is need to be signaled through the head end
   LER to the tail end LER, RSVP-TE signaling protocol need to be
   deployed in the MPLS/GMPLS network, or extend IGP protocol with node/
   adjacency segment identifiers signaling capability to be deployed.

   The PCECC solution introduced in
   [I-D.draft-zhao-pce-central-controller-user-cases] allow for a
   dynamic MPLS network that is eventually controlled and deployed
   without the deployment of RSVP-TE protocol or extended IGP protocol
   with node/adjacency segment identifiers signaling capability while
   providing all the key MPLS functionalities needed by the service
   providers.  In the case that one LSP path consist legacy network
   nodes and the new network nodes which are centrally controlled, the
   PCECC solution provides a smooth transition steps for the users.

   This draft specify the procedures and PCEP protocol extensions for
   using the PCE as the central controller and user cases where LSPs are
   calculated/setup/initiated/downloaded through extending the existing
   PCE architectures and PCEP.

2.  Terminology

   The following terminology is used in this document.








Zhao, et al.               Expires August 5, 2014                  [Page 5]


Internet-Draft                    PCECC                    November 2013


   IGP:  Interior Gateway Protocol.  Either of the two routing
      protocols, Open Shortest Path First (OSPF) or Intermediate System
      to Intermediate System (IS-IS).

   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.

   TE:  Traffic Engineering.

3.  PCEP Requirements

   Following key requirements associated PCECC should be considered when
   designing the PCECC based solution:

   1.  PCEP speaker supporting this draft MUST have the capability to
       advertise its PCECC capability to its peers.

   2.  Path Computation Element (PCE) supporting this draft MUST have
       the capability to negotiate a global label range for a group of
       clients.

   3.  Path Computation Client (PCC) MUST be able ask for global label
       range assigned in a request message .

   4.  PCE are not required to support label range reserve service.
       Therefore, it MUST be possible for a PCE to reject a label range
       reserve message with a reason code that indicates no support for
       label reserve service.

   5.  PCEP SHOULD provide a means to return global label range and LSP
       label assignments of the computed path in a reply message.

   6.  PCEP SHOULD provide a means to request for LSP setup in the
       request message.

   7.  PCEP SHOULD provide a means to download the MPLS forwarding entry
       to the PCECC's clients.

4.   Procedures for Using the PCE as the Central Controller (PCECC)

   The procdures specified in this document are based on the following
   PCECC architecture.




Zhao, et al.               Expires August 5, 2014                  [Page 6]


Internet-Draft                    PCECC                    November 2013


      +------------------------------------------------------------------+
      |                         PCECC                                    |
      |    +-----------------------------------------------------+       |
      |    |  LSP-Database    RSVP-TE Signal Control Module      |       |
      |    |  TE-Database     LDP signaling Control Module       |       |
      |    |  Label-Database  LP/label/TE MGRs                   |       |
      |    +-----------------------------------------------------+       |
      |    ^              ^           ^             ^        ^           |
      | IGP|LDP/RSVP-TE   |PCEP       |PCEP     PCEP|     IGP|LDP/RSVP-TE|
      |    |PCEP          |           |             |        |PCEP       |
      |    V              V           V             V        V           |
      | +--------+   +--------+   +--------+   +--------+   +--------+   |
      | |NODE 1  |   | NODE 2 |   | NODE 3 |   | NODE 4 |   | NODE 5 |   |
      | |        |...|        |...|        |...|        |...|        |   |
      | | Legacy |IGP|        |IGP|        |IGP|  PCC4  |IGP| Legacy |   |
      | |  Node  |   |        |   |        |   |        |   |  Node  |   |
      | +--------+   +--------+   +--------+   +--------+   +--------+   |
      |                                                                  |
      +------------------------------------------------------------------+


   Through the draft, we call the combination of the functionality for
   global label range signaling and the functionality of LSP setup/
   download/cleanup using the combination of global labels and local
   labels as PCECC functionality.

4.1.  Procedure-1 for PCECC Capability Advertisement

   During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
   advertise their support of PCECC extensions.  A PCEP Speaker includes
   the "PCECC Capability" TLV, described in Section 5.2.1.1. of this
   document, in the OPEN Object to advertise its support for PCECC
   extensions.

   The presence of the PCECC Capability TLV in PCC's OPEN Object
   indicates that the PCC is willing to function as a PCECC client.

   The presence of the PCECC Capability TLV in PCE's OPEN message
   indicates that the PCE is interested in function as a cental
   controller for LSP setup/download/label-reservation.

   The PCEP protocol extensions for PCECC MUST NOT be used if one or
   both PCEP Speakers have not included the PCECC Capability TLV in
   their respective OPEN message.  If the PCEP Speakers support the
   extensions of this draft but did not advertise this capability, then
   a PCErr with error-type TBD (Invalid Operation), error-value TBD
   (Attempted LSP setup/download/label-reservarion if PCECC capability
   was not advertised) will be generated and the PCEP session will be



Zhao, et al.               Expires August 5, 2014                  [Page 7]


Internet-Draft                    PCECC                    November 2013


   terminated.

4.2.  Procedure-2 for PCECC's Label Resource Reservations

   Current MPLS label has local meaning.  That is, MPLS label is always
   allocated by the downstream node to the upstream node.  Then the MPLS
   label is only identified by the neighboring upstream node and
   downstream node.  The label allocation is done locally and signaled
   through the LDP/RSVP-TE/BGP protocol.  To ease the label allocation
   and signaling mechanism, also with the new applications such as
   centralized LSP controllers are introduced, PCE can be conveniently
   used as a central controller and MPLS global label range negotiator.

   The label range reservation procedures are based on network
   configurations illustrated using the following figure:


      +------------------------------+    +------------------------------+
      |         PCE DOMAIN 1         |    |         PCE DOMAIN 2         |
      |          +--------+          |    |          +--------+          |
      |          |        |          |    |          |        |          |
      |          | PCECC1 |<------------------------>|  PCECC2|          |
      |          |        |          |    |          |        |          |
      |          |        |          |    |          |        |          |
      |          +--------+          |    |          +--------+          |
      |         ^          ^         |    |         ^          ^         |
      |        /            \        |    |        /            \        |
      |       V              V       |    |       V              V       |
      | +--------+        +--------+ |    | +--------+        +--------+ |
      | |NODE 11 |        | NODE 1n| |    | |NODE 21 |        | NODE 2n| |
      | |        | ...... |        | |    | |        | ...... |        | |
      | | PCECC  |        |  PCECC | |    | | PCECC  |        |PCECC   | |
      | |Enabled |        | Enabled|      | |Enabled |        |Enabled | |
      | +--------+        +--------+ |    | +--------+        +--------+ |
      |                              |    |                              |
      +------------------------------+    +------------------------------+


   Procedure-2 for global Label Range Reservation

   o  Node11 sends a label request message to PCECC1 with global label
      reservation range 100 to 1000.

   o  PCECC1 sends a reply message with global label reservation range
      100 to 1000 confirmed to node1, ..., node1n

   o  PCECC1 sends a indication message with global label reservation
      range 100 to 1000 confirmed to PCECC2.



Zhao, et al.               Expires August 5, 2014                  [Page 8]


Internet-Draft                    PCECC                    November 2013


   o  PCECC2 sends indication messages with global label reservation
      range 100 to 1000 confirmed to Node21,..., node2n

4.3.  Procedure-3 for PCECC for LSP Setup in the New PCECC Enabled
      Network

   Procedure-3-1: Tunnel Head End PCC-Initiated LSP Setup Using Global
   Label Range Reserved

   o  Node1 sends a path request message for LSP setup from Node11 to
      Node2n.

   o  PCE1 sends a indication message LSP setup with [Label(to2n),
      Node2n] to Node12, ..., Node1n.

   o  PCE1 sends a indication message LSP setup with [Label(to2n),
      Node2n] to PCE2;

   o  PCE2 sends a indication message LSP setup with [Label(to2n),
      Node2n] to Node22, ..., Node2n.

   Procedure-3-2: LSP Delete Using global Label Range Reserved

   o  Node1 sends a path request message for LSP cleanup from Node11 to
      Node2n.

   o  PCE1 sends a indication message LSP cleanup with [Label(to2n),
      Node2n] to Node12, ..., Node1n.

   o  PCE1 sends a indication message LSP cleanup with [Label(to2n),
      Node2n] to PCE2;

   o  PCE2 sends a indication message LSP cleanup with [Label(to2n),
      Node2n] to Node22, ..., Node2n.

4.4.  Procedure-4 for PCECC for LSP Setup in the Network Migration

   procedure-4 is based on network configurations illustrated using the
   following figure:












Zhao, et al.               Expires August 5, 2014                  [Page 9]


Internet-Draft                    PCECC                    November 2013


      +------------------------------------------------------------------+
      |                         PCE DOMAIN                               |
      |    +-----------------------------------------------------+       |
      |    |                       PCECC                         |       |
      |    +-----------------------------------------------------+       |
      |       ^                       ^            ^            ^        |
      |       |if11           RSVP-TE | if33   if44|RSVP-TE     |i55     |
      |       V                       V            V            V        |
      | +--------+   +--------+   +--------+   +--------+   +--------+   |
      | | NODE 1 |   | NODE 2 |   | NODE 3 |   | NODE 4 |   | NODE 5 |   |
      | |        |...|        |...|        |...|        |...|        |   |
      | | Legacy |if1| Legacy |if2|PCCEC   |if3| PCECC  |if4| Legacy |   |
      | |  Node  |   |  Node  |   |Enabled |   |Enabled |   |  Node  |   |
      | +--------+   +--------+   +--------+   +--------+   +--------+   |
      |                                                                  |
      +------------------------------------------------------------------+


   Procedures for Using PCECC Initiated LSP Setup In the Network
   Migration

   In this scenaro, there are multiple nodes for the LSP from head end
   (node1) to the tail end (node5).  Where the node3 and node4 with the
   PCECC capability, and other nodes are legacy nodes.

   o  Node1 sends a path request message for LSP setup to Node5.

   o  PCE sends a reply message for LSP setup with path (node1, i1),
      (node2, i2), (node-PCECC, if33), (node-PCECC, if55), Nnode5.

   o  PCE sends an indication message for LSP segment setup with
      [Label(toN5), Node5] for node3 to node4.

   o  Node1, Node2, Node-PCECC, Node-PCECC, Node 5 will setup the LSP to
      Node5 normally using the local label as normal.  After the LSP is
      setup, then the PCECC will program the node 3 and node 4 to
      replace the LSP segment from node3-node-PCECC-node5 to node3-
      node4-node5.

4.5.   Procedure-5 for Using Extended PCEP to download LSP information
      for Each Network Device

   The existing PCEP is used to communicate between the PCE server and
   PCC for exchanging the path request and reply information regarding
   to the LSP info.  With minor extensions, we can use the PCEP to
   download the complete LSP forwarding entries for each node in the
   network.




Zhao, et al.               Expires August 5, 2014                 [Page 10]


Internet-Draft                    PCECC                    November 2013


   In procedure-5, the LSP segment between node3 and node4 for
   destination node5 is setup from PCECC and downloaded into node3 and
   node4 directly from PCECC through the extended PCEP.


      +------------------------------------------------------------------+
      |                         PCE DOMAIN                               |
      |    +-----------------------------------------------------+       |
      |    |                       PCECC                         |       |
      |    +-----------------------------------------------------+       |
      |                          PCEP |       PCEP|                      |
      |               MPLS Forwarding |           | MPLS Forwarding      |
      |                Entry Download V           V Entry Download       |
      | +--------+   +--------+   +--------+   +--------+   +--------+   |
      | | NODE 1 |   | NODE 2 |   | NODE 3 |   | NODE 4 |   | NODE 5 |   |
      | |        |...|        |...|        |...|        |...|        |   |
      | | Legacy |if1| Legacy |if2|PCCEC   |if3| PCECC  |if4| Legacy |   |
      | |  Node  |   |  Node  |   |Enabled |   |Enabled |   |  Node  |   |
      | +--------+   +--------+   +--------+   +--------+   +--------+   |
      |                                                                  |
      +------------------------------------------------------------------+


5.  PCEP Extensions

   As defined in [RFC5440], a PCEP message consists of a common header
   followed by a variable-length body made of a set of objects that can
   be either mandatory or optional.  An object is said to be mandatory
   in a PCEP message when the object must be included for the message to
   be considered valid.  For each PCEP message type, a set of rules is
   defined that specify the set of objects that the message can carry.
   An implementation MUST form the PCEP messages using the object
   ordering specified in this document.

5.1.  New Messages

   In this document, we define the following new PCEP messages:














Zhao, et al.               Expires August 5, 2014                 [Page 11]


Internet-Draft                    PCECC                    November 2013


       (LabelRRq): a PCEP message sent by a PCC
         to a PCE to ask for the gloabl label range reservation.

       (LabelRN): a PCEP message sent by a PCE
         to a PCC to indicate the globallabel range reserved.

       (LSPSetupRq):  a PCEP message sent by a PCC
         to a PCE to ask for the setup of LSPs. </t>

       (LSPSetupRq):  a PCEP message sent by a PCC
         to a PCE to ask for the delete of LSPs. </t>

       (LFIBdownload): a PCEP message sent by a PCE
         to a PCC to download the LFIB.

      (LFIBCleanup): a PCEP message sent by a PCE
         to a PCC to download the LFIB.



   The new functions defined in this document are mapped onto the new
   messages as shown in the following table.


   +----------------------------------------+--------------------------+
   | Function                               | Message                  |
   +----------------------------------------+--------------------------+
   | LSP Label Range Reserve Request        | LabelRRq                 |
   | LSP Label Range Reserve Notify         | LabelRN                  |
   | LSP Setup Request                      | LSPSetupRq               |
   | LSP Delete Request                     | LSPDeleteRq              |
   | LIFB Download                          | LFibDownLoad             |
   | LIFB Cleanup                           | LFibCleanup              |
   +----------------------------------------+--------------------------+


5.1.1.  PCEP Extension for Label Range Reservation Request

   A Label Range Request message (also referred to as LabelRRq message)
   is a PCEP message sent by a PCC or an application to a PCE to request
   the setup of an LSP.  The Message-Type field of the PCEP common
   header for the LabelRRq message is set to [TBD].

   The format of a LabelRRq message is as follows:







Zhao, et al.               Expires August 5, 2014                 [Page 12]


Internet-Draft                    PCECC                    November 2013


      <LabelRRq Message>::= <Common Header>
                             <label-range-request>
   Where:

    <label-range-request> ::= <SRQ>
                            <minimum-lable><maximum-label>
      <lable> is as defined in [RFC3209].


   There are three mandatory objects that MUST be included within each
   label range Request in the labelRRq message: the SQR Object, two
   label objects.  If the SQR object is missing, the receiving PCE MUST
   send a PCErr message.  If the label object is missing, the receiving
   PCE MUST send a PCErr message with Error- type=[TBD] (Mandatory
   Object missing) and Error-value=[TBD] (Lable object missing).

   A PCE only acts on an label range reservation equest if permitted by
   the local policy configured by the network manager.  Each label range
   reservation Request that the PCC acts on results in an LSP setup
   operation.  An LSP MUST contain all LSP parameters that a PCC need to
   resrve the label range.  A PCC MAY set missing parameters from
   locally configured defaults.

5.1.2.  PCEP Extension for Label Range reservation Notify

   The Label Range Notify Message (also referred to as LabelRN) is a
   PCEP message sent by a PCE to a PCC to notify the global label range
   reserved for the network.  The Message-Type field of the PCEP common
   header for the LabelRN message is set to [TBD].

   The format of the LabelRN message is as follows:


   <LabelRN Message>> ::= <Common Header>
                       [<SRQ>]
                       <Minimum-Lable><Maxmum-Label>
Where:
   the label range is between Minumum-Lable and Maxmum-Lable, which is as defined
   as the <label> object in {RFC3209].


   The SRQ object is optional.  If the LabelRN message is not in
   response to a LableRRq message, the SRQ object MAY be omitted.

   If the LabelRN message is not in response to a LableRRq message, the
   SRQ object SHOULD be included and the value of the SRQ-ID-number in
   the SRQ Object MUST be the same as that sent in the LabelRRq message
   that triggered the LSP to be setup.



Zhao, et al.               Expires August 5, 2014                 [Page 13]


Internet-Draft                    PCECC                    November 2013


5.1.3.  The LSP Setup Request Message

   A LSP Setup Request message (also referred to as LSPSetupRq message)
   is a PCEP message sent by a PCC or an application to a PCE to request
   the setup of an LSP.  A LSPSetupRq message can carry more than one
   LSP Setup Request.  The Message-Type field of the PCEP common header
   for the PCUpd message is set to [TBD].

   The format of a LSPSetupRq message is as follows:


   <LSPSetupRq Message> ::= <Common Header>
                            <lspsetup-request-list>
Where:

   <lspsetup-request-list> ::= <lspsetup-request>[<lspsetup-request-list>]

   <lspsetup-request> ::= <SRQ>
                          <LSP>
                          [<attribute-list>]

Where:
   <attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
   <LSP> and <lable> are as defined in [RFC3209].


   A PCC only acts on an LSP Setup Request if permitted by the local
   policy configured by the network manager.  Each LSP Setup Request
   that the PCC acts on results in an LSP setup operation.  An LSP Setup
   Request MUST contain all LSP parameters that a PCE wishes to be set
   for the LSP.  A PCC MAY set missing parameters from locally
   configured defaults.  If the LSP specified in the Setup Request is
   already up, it will be re-downloaded.

5.1.4.  The LSP Delete Request Message

   A LSP Delete Request message (also referred to as LSPDeleteRq
   message) is a PCEP message sent by a PCC or an application to a PCE
   to request the delete of an LSP.  A LSPDeleteRq message can carry
   more than one LSP Delete Request.  The Message-Type field of the PCEP
   common header for the PCUpd message is set to [TBD].

   The format of a LSPDeleteRq message is as follows:








Zhao, et al.               Expires August 5, 2014                 [Page 14]


Internet-Draft                    PCECC                    November 2013


   <LSPDeleteRq Message> ::= <Common Header>
                            <lspsetup-request-list>
Where:

   <lspdelete-request-list> ::= <lspdelete-request>[<lspdelete-request-list>]

   <lspdelete-request> ::= <SRQ>
                          <LSP>


   There is one mandatory object that MUST be included within each LSP
   delete Request in the LSPdeleteRq message: the LSPObject.

   A PCE only acts on an LSP delete Request if permitted by the local
   policy configured by the network manager.  Each LSP Setup Request
   that the PCC acts on results in an LSP delete operation.  An LSP
   delete Request MUST contain all LSP parameters that a PCE wishes to
   be delete for the LSP.  A PCE MAY set missing parameters from locally
   configured defaults.  If the LSP specified in the delete Request is
   already delete, it will be assume the delete is done.

5.1.5.  PCEP Extension for LFIB Entry Downloading

   The LFIB Entry Downloading Message (also referred to as LfibDownLoad)
   is a PCEP message sent by a PCE to a PCC to download the LFIB for a
   LSP.  The Message-Type field of the PCEP common header for the
   LfibDownLoad message is set to [TBD].

   The format of the LfibDownLoad message is as follows:


   <LfibDownLoad Message> ::= <Common Header>
                              <LFIB-list>
Where:

   <LFIB-list> ::= <LFIB>[<LFIB-lis>]

   <LFIB>::= [<SRQ>]
              <LSP>
              <path>
 Where:
   <path>::= [in-label]<ERO>[out-label]<attribute-list>

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


   The SRQ object is optional.  If the LfibDownLoad message is not in



Zhao, et al.               Expires August 5, 2014                 [Page 15]


Internet-Draft                    PCECC                    November 2013


   response to a LSPSetupRq message, the SRQ object MAY be omitted.

   If the LfibDownLoad message is in response to a LSPSetuoRq message,
   the SRQ object SHOULD be included and the value of the SRQ-ID-number
   in the SRQ Object MUST be the same as that sent in the LfibDownLoad
   message that triggered the LSP to be setup.

   The LSP object is mandatory, and it MUST be included in each
   Lfibbdownload message.

5.1.6.  PCEP Extension for LFIB Entry Cleanup

   The LFIB Entry Cleanup Message (also referred to as LfibDownLoad) is
   a PCEP message sent by a PCE to a PCC to cleanup the LFIB for a LSP.
   The Message-Type field of the PCEP common header for the LfibDownLoad
   message is set to [TBD].

   The format of the LfibCleanup message is as follows:


   <LfibCleanup Message> ::= <Common Header>
                              <LFIB-list>
Where:

   <LFIB-list> ::= <LFIB>[<LFIB-lis>]

   <LFIB>::= [<SRQ>]
              <LSP>
              <path>
 Where:
   <path>::= [in-label]<ERO>[out-label]<attribute-list>

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


   The SRQ object is optional.  If the LfibCleanup message is not in
   response to a LSPDeleteRq message, the SRQ object MAY be omitted.

   If the LfibCleanup message is in response to a LSPDeleteRq message,
   the SRQ object SHOULD be included and the value of the SRQ-ID-number
   in the SRQ Object MUST be the same as that sent in the LfibCleanup
   message that triggered the LSP to be setup.

   The LSP object is mandatory, and it MUST be included in each
   Lfibbdownload message.





Zhao, et al.               Expires August 5, 2014                 [Page 16]


Internet-Draft                    PCECC                    November 2013


5.1.7.  The PCErr Message

   [TBD]

5.2.  Object Formats

   The PCEP objects defined in this document are compliant with the PCEP
   object format defined in [RFC5440].  The P flag and the I flag of the
   PCEP objects defined in this document MUST always be set to 0 on
   transmission and MUST be ignored on receipt since these flags are
   exclusively related to path computation requests.

5.2.1.  OPEN Object

   This document defines two new optional TLVs for use in the OPEN
   Object.

5.2.1.1.  PCECC Capability TLV

   The PCECC-CAPABILITY TLV is an optional TLV for use in the OPEN
   Object for PCECC capability advertisement.  Its format 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=[TBD]      |            Length=4           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Flags                           |U|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





   The type of the TLV is [TBD] and it has a fixed length of 4 octets.

   The value comprises a single field - Flags (32 bits):

   U (LFIB-SETUP-CAPABILITY - 1 bit):  if set to 1 by a PCC, the U Flag
      indicates that the PCC allows the download of LFIB; if
      set to 1 by a PCE, the U Flag indicates that the PCE is capable of
      download LFIB parameters.  The LFIB-SETUP-CAPABILITY Flag must be
      advertised by both a PCC and a PCE for LSPSetup/LfibDownload messages to be
      allowed on a PCEP session.





Zhao, et al.               Expires August 5, 2014                 [Page 17]


Internet-Draft                    PCECC                    November 2013


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

   Advertisement of the PCECC capability implies support of LSPs that
   are setup through PCECC, as well as the objects, TLVs and procedures
   defined in this document.

5.2.2.  SRQ Object

   The details of format for the SRQ are [TBD].

6.  IANA Considerations

   [TBD].

7.  Manageability Considerations

   [TBD]

8.  Security Considerations

   [TBD]

9.  Acknowledgments

   We would like to thank Robert Tao, Changjing Yan, Tieying Huang for
   their useful comments and suggestions.

10.  References

10.1.  Normative References

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

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

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

10.2.  Informative References

   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, September 1999.

Zhao, et al.               Expires August 5, 2014                 [Page 18]


Internet-Draft                    PCECC                    November 2013


   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

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

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

Authors' Addresses

   Quintin Zhao
   Huawei Technologies
   125 Nagog Technology Park
   Acton, MA  01719
   US

   EMail: quintin.zhao@huawei.com


   Katherine Zhao
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   EMail: Katherine.zhao@huawei.com


   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   EMail: lizhenbin@huawei.com














Zhao, et al.               Expires August 5, 2014                 [Page 19]


Internet-Draft                    PCECC                    November 2013


   Dhruv Dhody
   Huawei Technologies
   Leela Palace
   Bagalore, Karnataka  560008
   India

   EMail: dhruv.ietf@gmail.com


   Boris Zhang
   Telus Ltd.
   Toronto
   Canada

   EMail: Boris.Zhang@Boris.zhang@telus.com




































Zhao, et al.               Expires August 5, 2014                 [Page 20]


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