Internet Engineering Task Force                             Q. Zhao, Ed.
Internet-Draft                                         Huawei Technology
Intended Status: Standards Track                        Daniel King
Expires: February 19, 2010 King, Ed.
Created: October 25, 2009                             Old Dog Consulting
                                                         August 18, 2009
Expires: March 25, 2010

    Extensions to the Path Computation Element Communication Protocol
(PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
               draft-ietf-pce-pcep-p2mp-extensions-04.txt
               draft-ietf-pce-pcep-p2mp-extensions-05.txt

Abstract

   Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
   MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
   be established using signaling techniques, but their paths may first
   need to be determined.  The Path Computation Element (PCE) has been
   identified as an appropriate technology for the determination of the
   paths of P2MP TE LSPs.

   This document describes extensions to the PCE communication Protocol
   (PCEP) to handle requests and responses for the computation of paths
   for P2MP TE LSPs.

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

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

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

   This Internet-Draft will expire on January 28, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Abstract

   Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
   MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
   be established using signaling techniques, but their paths may first
   need to be determined.  The Path Computation Element (PCE) has been
   identified as an appropriate technology for the determination of the
   paths of P2MP TE LSPs.

   This document describes extensions to the PCE communication Protocol
   (PCEP) to handle requests and responses for the computation of paths
   for P2MP TE LSPs.

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

Table of Contents
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .4 .
     1.1 Terminology  . . . . . . . . . . . . . . . . . . . . . . . .5 .
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .5 .
   3.  Protocol Procedures and Extensions . . . . . . . . . . . . . .6 .
     3.1.  P2MP Capability Advertisement  . . . . . . . . . . . . . .6 .
       3.1.1.  Extend the  P2MP Computation TLV in the Existing PCE Discovery
               Protocol . . . . . . . . . . . . . . . . . . . . . . .6 .
       3.1.2.  Open Message Extension . . . . . . . . . . . . . . . .6 .
     3.2.  P2MP LSPs  Efficient Presentation of P2MP TE LSPs . . . . . . . . . . . . .7
     3.3.  P2MP Path Computation Request/Reply Message Extensions . .7 .
       3.3.1.  The Extension of the RP Object . . . . . . . . . . . . . .7
       3.3.2.  The New P2MP END-POINTS Object . . . . . . . . . . . .8 .
     3.4.  Request Message Formats Format . . . . . . . . . . . . . . . . . . .10
     3.5.  Reply Message Formats Format . . . . . . . . . . . . . . . . . . . .11
     3.6.  P2MP Objective Functions and Metric Types  . . . . . . . .12 .
       3.6.1.  New Object Functions . . . . . . . . . . . . . . . . .12 .
       3.6.2.  New Metric Object Types  . . . . . . . . . . . . . . .13 .
     3.7.  Non-Support of P2MP Path Computation.  . . . . . . . . . .13 .
     3.8.  Non-Support by Back-Level PCE Implementations. . . . . . .13 .
     3.9.  P2MP TE Path Re-optimization Reoptimization Request . . . . . . . . . . .13 .
     3.10. Adding/pruning Adding and Pruning Leaves to the P2MP Tree . . . . . . . . . . . . . . . . . .14
     3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . . . . . . . .17
     3.12. Synchronization of P2MP TE Path Computation Requests . . .17 .
     3.13. Request and Response Fragmentation . . . . . . . . . . . .19 .
       3.13.1 Request Fragmentation Procedure . . . . . . . . . . . .19 .
       3.13.2 Response Fragmentation Procedure  . . . . . . . . . . .19 .
       3.13.3 Fragmentation Examples  . . . . . . . . . . . . . . . .19 .
     3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . .20 .
     3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . .21 .
     3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .22 .
   4.  Manageability Considerations . . . . . . . . . . . . . . . . .22 .
     4.1.  Control of Function and Policy . . . . . . . . . . . . . .23 .
     4.2.  Information and Data Models  . . . . . . . . . . . . . . .23 .
     4.3.  Liveness Detection and Monitoring  . . . . . . . . . . . .23 .
     4.4.  Verifying Correct Operation  . . . . . . . . . . . . . . .23 .
     4.5.  Requirements on Other Protocols and Functional
           Components . . . . . . . . . . . . . . . . . . . . . . . .23 .
     4.6.  Impact on Network Operation  . . . . . . . . . . . . . . .23 .
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .23 .
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .24
     6.1 .
     6.1.  P2MP Capability TLV  . . . . . . . . . . . . . . . . . . .24
     6.2   Object Functions . . . . .
     6.2.  Request Parameter Bit Flags  . . . . . . . . . . . . . . . .24
     6.3   Metric
     6.3.  Object Types Function  . . . . . . . . . . . . . . . . . . .24
     6.4   UNREACH_DESTINATION objects . . .
     6.4.  Metric Object Types  . . . . . . . . . . . .24
     6.5   P2MP . . . . . . . .
     6.5.  PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .
     6.6.  PCEP Error Objects and Types . . . . . . . . . . . .24
     6.6   SERO and SRO Object-Class . . . .
     6.7.  PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . .25

   7.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . .25 .
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .25 .
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .25 .
     8.2.  Informative References . . . . . . . . . . . . . . . . . .26 .
   9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .26 .
     9.1.  Contributors . . . . . . . . . . . . . . . . . . . . . . .27 .
   Appendix A. RBNF Code Fragments  . . . . . . . . . . . . . . . . .27 .

1.  Introduction

   The Path Computation Element (PCE) defined in [RFC4655] is an entity
   that is capable of computing a network path or route based on a
   network graph, and applying computational constraints.  A Path
   Computation Client (PCC) may make requests to a PCE for paths to be
   computed.

   [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
   Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

   The PCE has been identified as a suitable application for the
   computation of paths for P2MP TE LSPs [PCE-P2MP-APP].

   The PCE communication protocol (PCEP) is designed as a communication
   protocol between PCCs and PCEs for point-to-point (P2P) path
   computations and is defined in [RFC5440].  However, that
   specification does not provide a mechanism to request path
   computation of P2MP TE LSPs.

   This document presents extensions to PCEP to support P2MP path
   computation satisfying the set of requirements described in [PCE-
   P2MP-REQ].

   This document relies on the mechanisms of PCEP for requesting path
   computation for P2MP TE LSPs.  A P2MP LSP is comprised of multiple
   source-to-leaf (S2L) sub-LSPs.  These S2L sub-LSPs are set up between
   ingress and egress LSRs and are appropriately combined by the branch
   LSRs using computation results from the PCE to determine the path of
   a P2MP TE LSP.

   One request message from a PCC may signal one or more S2L sub-LSP
   path computation requests to the PCE for a single P2MP LSP with
   certain constraints.  Hence the S2L sub-LSPs belonging to a P2MP LSP
   can use one path computation request message or be split across
   multiple path computation messages.

1.1  Terminology

   Terminology used in this document.

   TE LSP: Traffic Engineered Label Switched Path.

   LSR: Label Switch Router.

   OF: Objective Function: A set of one or more optimization criterion
   (criteria) used for the computation of a single path (e.g. path cost
   minimization), or the synchronized computation of a set of paths
   (e.g. aggregate bandwidth consumption minimization, etc.).

   P2MP: Point-to-Multipoint.

   P2P: Point-to-Point.

   This document also uses the terminology defined in [RFC4655],
   [RFC4875], and [RFC5440].

2.  Requirements

   This section summarizes the PCEP requirements specific to Point to
   Multipoint as PCC-PCE Communication Requirements for
   P2MP MPLS-TE LSPs described in [PCE-P2MP-REQ].

   R1: [PCE-P2MP-REQ]:

   1. Indication of P2MP Path Computation Request.

   R2: Request

   2. Indication of P2MP Objective Functions.

   R3: Functions

   3. Non-Support of P2MP Path Computation.

   R4:

   4. Non-Support by Back-Level PCE Implementations.

   R5:

   5. Specification of Destinations.

   R6: Destinations

   6. Indication of P2MP Paths.

   R7: Paths

   7. Multi-Message Requests and Responses.

   R8: Responses

   8. Non-Specification of Per-Destination Constraints and Parameters.

   R9: Parameters

   9. Path Modification and Path Diversity.

   R10: Diversity

   10. Reoptimization of P2MP TE LSPs.

   R11: LSPs

   11. Addition and Removal of Destinations from Existing Paths.

   R12: Paths

   12. Specification of Applicable Branch Nodes.

   R13: Nodes
   13. Capabilities Exchange.

   The following additional requirements have also been identified:

   R14: The PCC should be able to request a PCE to compute secondary
   P2MP path tree with partial path diversity for specific leaves or a
   specific S2L sub-path.

   R15: Sender of the request message can specify if the return result
   from the PCE need to be represented in the compressed format or not. Exchange

   14. Path-Tree Diversity

3.  Protocol Procedures and Extensions

   The following section describe describes the protocol extensions required to
   satisfy the requirements specified in the requirements Requirements section
   (section 2).
   (Section 2) of this document.

3.1.  P2MP Capability Advertisement

3.1.1. Extend the  P2MP Computation TLV in the Existing PCE Discovery Protocol

   Since [RFC5088] has specified that we cannot add an additional
   sub-TLV (type-length-value) to the PCEP TLV, we will define s a new
   bit to go in the existing 32 bit PCE capabilities flags to indicate
   the capability of P2MP computation.

3.1.2.  Open Message Extension

   Based on the Capabilities Exchange requirement described in [PCE-
   P2MP-REQ],
   [PCE-P2MP-REQ], if a PCE does not advertise its P2MP capability
   during
   discovery and the PCC does not have an alternative PCE capable of
   P2MP computation. We need to use discovery, PCEP should be used to allow a PCC to discover
   which PCEs with which it communicates support are capable of supporting P2MP path computation.

   To satisfy this requirement, we extend the OPEN object format by
   including a new defined TLV for the capability of P2MP in the
   optional field.  The new defined capability TLV allows the PCE to
   advertise its P2MP path computation capability.

   The TLV type number will be assigned by IANA, IANA and is requested in the LENGTH
   IANA Considerations section (Section 6) of this document. The length
   value is 2 bytes.  The value field is set to default value 0.

   Note that the capability TLV is meaningful only for a PCE so it will
   typically appear only in one of the two Open messages during PCE
   session establishment.  However, in case of PCE cooperation (e.g.,
   inter-domain), when a PCE behaving as a PCC initiates a PCE session
   it SHOULD also indicate its path computation capabilities.

3.2. P2MP LSPs  Efficient Presentation of P2MP LSPs

   When specifying additional leaves, or optimizing existing P2MP TE
   LSPs as specified in [PCE-P2MP-REQ], we need it may be necessary to pass
   existing P2MP LSP route information between the PCC and PCE in the
   request and reply message. In each of these scenarios, we need new
   path objects for efficiently passing the existing P2MP LSP between
   the PCE and PCC.

   We specify the use of the Explicit Route Object (ERO)
   to encode the explicit route of a TE LSP through the network. The
   Secondary Explicit Route object Object (SERO) is used to specify the
   explicit route of a S2L sub-LSP. The Reported Route Object (RRO) and
   Secondary Reported Route Object (SERO) are used to report
   the routes of existing TE LSP for which a reoptimization is
   desired. The format and contents of the ERO and RRO are defined in
   [RFC5440]. The format and contents of the SERO and SRRO are
   defined in [RFC4875]. A new class and type are requested for SERO
   and SRRO in the IANA Considerations section of this document.

3.3.  P2MP Path Computation Request/Reply Message Extensions

   The existing P2P RP (Request Parameters) object is extended so that
   it can signal to the receiver of the PCEP request that it is for
   P2P or P2MP path computation.  Also the END-POINT object is
   extended to improve the efficiency of the message exchange between
   PCC and PCE in the case of P2MP path computation.

3.3.1.  The Extension of the RP Object

   The PCE path computation request and reply message will need the
   following additional parameter parameters to allow a receiving PCE to
   identify that the request and reply message has been fragmented
   across multiple messages, is has been requested for a P2MP path and to
   specify if the route is represented in the compressed format or not. uncompressed
   format.

   The F bit is added to the flag bits of the RP object to indicate
   to the receiver that the request is part of a fragmented request, or
   is not a fragmented request.

   The M bit is added in the flag bits field of the RP object to signal
   the receiver of the message that the request/reply is for P2MP or
   not.

   The E bit is added in the flag bits field of the RP object to signal
   the receiver of the message that the route is in the compress format
   or not.

   The extended format of the RP object body to include the F bit, M
   bit and the E bit is as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Reserved   | Flags         |F|E|M|             |F|N|E|         |O|B|R| Pri |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Request-ID-number                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                      Optional TLV(s)                        //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 1: RP Object Body Format

  The following flags are added in this draft:

   o  M  F ( P2MP RP fragmentation bit - 1 bit):

         0: This indicates that this the RP is not PCReq/PCRrep for P2MP. fragmented or it is the
            last piece of the fragmented RP.

         1: This indicates that the RP is fragmented and this is PCReq or PCRep message for P2MP. not
            the last piece of the fragmented RP and the receiver
            needs to wait until it receives an RP with the same RP-ID
            and with the F bit is set to 0.

   o  E  N ( ERO-compression P2MP bit - 1 bit):

         0: This indicates that the route this is not in the compressed
         format. PCReq/PCRrep for P2MP.

         1: This indicates that the route this is in the compressed format. PCReq or PCRep message for P2MP.

   o  F  E ( RP fragmentation ERO-compression bit - 1 bit):

         0: This indicates that the RP route is not fragmented or it is the
            last piece of in the fragmented RP. compressed
         format.

         1: This indicates that the RP is fragmented and this route is not
            the last piece of the fragmented RP and the receiver
            need to wait until it receives an RP with the same RP-ID
            and with in the F bit is set to 0. compressed format.

3.3.2.  The New P2MP END-POINTS Object

   To represent the end points for a P2MP path efficiently, we define a
   new type of end-points object for the P2MP path.

   With this the new END-POINTS object, the PCE path computation request
   message is expanded in a way such that it which allows a single request
   message to list multiple destinations.

   There are 4 types of leaves in a P2MP request:

   o  New leaves to add;
   o  Old leaves to remove;
   o  Old leaves whose path can be modified/reoptimized;
   o  Old leaves whose path must be left unchanged.

   A given END-POINTS object gathers the leaves of a given type.  The
   type of leaf in a given END-POINTS object is identified by the END-
   POINTS object leaf type field.

   So four
   Four values are possible for the leaf type field:

   1.  New leaves to add;
   2.  Old leaves to remove;
   3.  Old leaves whose path can be modified/reoptimized;
   4.  Old leaves whose path must be left unchanged.

   With this the new END-POINTS object, the END-POINTS portions portion of a request
   message for the multiple destinations can be roughly reduced by up to 50% for
   a P2MP path where a single source address has a very large number of
   destinations.

   Note that A a P2MP path computation request can mix the different type types
   of leaves by including several END-POINTS object per RP object as
   shown in PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format in
   next section.
   following Request Message Formats section (Section 3.4).

   The format of the new END-POINTS object body for IPv4 (Object-Type 3)
   is as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Leaf type                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Source IPv4 address                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Destination IPv4 address                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                           ...                                 ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Destination IPv4 address                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 2: The New P2MP END-POINTS Object Body Format for IPv4

   The format of the END-POINTS object body for IPv6 (Object-Type 4) is
   as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Leaf type                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                Source IPv6 address (16 bytes)                 |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |              Destination IPv6 address (16 bytes)              |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                           ...                                 ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |              Destination IPv6 address (16 bytes)              |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 3: The New P2MP END-POINTS Object Body Format for IPv6

   The END-POINTS object body has a variable length of multiple length. These are multiples
   of 4 bytes for IPv4 IPv4, and multiple multiples of 16 bytes for IPv6.

3.4.  Request Message Formats Format

   As per [RFC5511] the RBNF format of the PCReq message is as follows.
   Please see Appendix A for a full set of RBNF fragments defined in
   this document and the necessary code license.

   Below is the message format for the request message:

           <PCReq Message>::= <Common Header>
                                 <request>
        where:
                <request>::= <RP>
                                <end-point-rro-pair-list>
                                [<OF>]
                                [<LSPA>]
                                [<BANDWIDTH>]
                                [<metric-list>]
                                [<IRO>]
                                [<LOAD-BALANCING>]

        where:

                <end-point-rro-pair-list>::=
                                   <END-POINTS>[<RRO-List>][<BANDWIDTH>]
                                   [<end-point-rro-pair-list>]

                <RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
                <metric-list>::=<METRIC>[<metric-list>]

           Figure 4: The Message Format for the Request Message

   Note we preserve compatibility with the [RFC5440] definition of
   <request>. At least one instance of <endpoints> must be present
   in this definition.

3.5.  Reply Message Formats Format

   As per [RFC5511] the RBNF format of the PCRep message is as follows.
   Please see Appendix A for a full set of RBNF fragments defined in
   this document and the necessary code license.

   Below is the message format for the reply message:

          <PCRep Message>::= <Common Header>
                                <response>
          <response>::=<RP>
                          [<end-point-path-pair-list>]
                          [<NO-PATH>]
                          [<attribute-list>]

        where:

           <end-point-path-pair-list>::=
                   [<END-POINTS>]<path>[<end-point-path-pair-list>]

          <path> ::=(ERO)|(SERO)|<path>]

          <attribute-list>::=[<OF>]
                               [<LSPA>]
                               [<BANDWIDTH>]
                               [<metric-list>]
                               [<IRO>]

            Figure 5: The Message Format for the Reply Message

   The optional END-POINTS in the reply message is used to specify which
   paths are removed, changed, not changed, or added for the request.
   The path is only needed for the end points which are added or
   changed.

   If the ERO-Compress bit was set to 1 in the request then the path
   will be formed by an ERO followed by a list of SERO.  Otherwise it
   is a list of ERO.

   Note that we preserve compatibility with the [RFC5440] definition of
   <response> and the optional <end-point-pair-list> and <path>.

3.6. P2MP Objective Functions and Metric Types

3.6.1.  New Object Functions

   Six objective functions have been defined in [RFC5541] for P2P path
   computation.

   This document defines two additional objective functions, namely SPT
   (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP
   path computation.  Hence two new objective function codes have to be
   defined.
   The description of the two new objective functions is as follows.

   Objective Function Code: 7 (suggested value, to be assigned by IANA)

   Name: Shortest Path Tree (SPT)

   Description: Minimize the maximum source-to-leaf cost with respect to
   a specific metric or to the TE metric used as the default metric when
   the metric is not specified. (e.g.  TE or IGP metric)

   Objective Function Code: 8 (suggested value, to be assigned by IANA)

   Name: Minimum Cost Tree (MCT)

   Description: Minimize the total cost of the tree, that is the sum of
   the costs of tree links, with respect to a specific metric or to the
   TE metric used as the default metric when the metric is not
   specified.
   Processing these two new objective functions is subject to the rules
   defined in [RFC5541].

3.6.2.  New Metric Object Types

   There are three types defined for the <METRIC> object in [RFC5440],
   namely, the IGP metric, the TE metric and the Hop Count metric.  This
   document defines three other types for the <METRIC> object: the P2MP
   IGP metric, the P2MP TE metric, and the P2MP Hop Count hop count metric.  They
   encode the sum of the metrics of all links of the tree.  We propose
   the following values for these new metric types:

   o  P2MP IGP metric: T=8 (suggested value, to be assigned by IANA)

   o  P2MP TE metric: T=9 (suggested value, to be assigned by IANA)

   o  P2MP hop count metric: T=10 (suggested value, to be assigned by
      IANA)

3.7.  Non-Support of P2MP Path Computation.

   o  If a PCE receives a P2MP path request and it understands the P2MP
      flag in the RP object, but the PCE is not capable of P2MP
      computation, the PCE MUST send a PCErr message with a PCEP-ERROR
      Object and corresponding Error-Value.  The original P2MP path
      computation request MUST then be cancelled. New Error-Types and
      Error-Values are requested in the IANA Considerations section of
      this document.

   o  If the PCE does not understand the P2MP flag in the RP object,
      then the PCE MUST send a PCErr message with a new error type
      "Unknown RP flag".

3.8.  Non-Support by Back-Level PCE Implementations.

   If a PCC inadvertently sends the a P2MP request to a PCE which does not
   support P2MP path computation and therefore the PCEP P2MP extensions,
   then it the PCE SHOULD reject the request request,
   because it cannot understand the new P2MP END-POINTS object.

3.9.  P2MP TE Path Re-optimization Reoptimization Request

   The re-optimization

   A reoptimization request for a P2MP TE path is specified by the use
   of the R bit
   in within the RP object similarly as defined in [RFC5440] and is
   similar to the re-optimization reoptimization request for a P2P TE path.  The only
   difference is that the user must insert the list of RRO RROs and SRRO SRROs
   after each type of END-POINTS as described in the PCReq message format section.

   So message, as described in
   the Request Message Format section (Section 3.4) of this document.

   An example of a reoptimization request and subsequent PCReq message would look like this:
   is described below:

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 3
             RRO list
           OF (optional)

            Figure 6: PCReq Message Example 1 for Optimization

  In this example, we request re-optimization reoptimization of path to all leaves
  without adding or pruning leaves.  That is only one END-POINT of type
  3.  The RRO list is representing the P2MP LSP before the optimization
  and the modifiable path leaves are indicated in the END-POINTS
  object.

  Optionally it is possible to specify some specific leaves whose path cannot
  be modified.  The  An example of the PCReq message in this scenario would then look like this:
  be:

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 3
             RRO list
           END-POINTS for leaf type 4
             RRO list
           OF (optional)

            Figure 7: PCReq Message Example 2 for Optimization

3.10.  Adding/pruning  Adding and Pruning Leaves to the P2MP Tree

   When adding new leaves or removing old leaves to the existing P2MP
   tree, by supplying a list of existing leaves, one may it SHOULD be able possible
   to optimize the new existing P2MP tree.  This section explains ways the
   methods to add new leaves or remove old leaves to the existing
   P2MP tree.

   To add new leaves the user must build a P2MP request with an END-
   POINTS with leaf type 1.

   To remove old leaves the user must build a P2MP request with an END-
   POINTS with leaf type 2.

   In any case it

   The PCC must also provide the list of old leaves and indicate if they must
   should be reoptimized or not by including END-POINTS with leaf type 3
   or  4 or both.  This document also define  The error values when the
   condition is conditions are not
   satisfied (i.e., when there is no END-POINTS with leaf type 3 or
   4, in the presence of END-POINTS with leaf type 1 or 2). This 2), are
   documented in the IANA Considerations section. section (Section 6) of this
   document.

   For old leaves the user must provide the old path as list of RROs
   that immediately follows each END-POINTS object. This document
   specifies error values when specific conditions are not satisfied.

   The following cases are possible when modifying an examples demonstrate full and partial reoptimization of
   existing P2MP
   LSP: LSPs:

   Case 1: Adding leaves with full reoptimization of existing paths

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 3 1
             RRO list
           END-POINTS for leaf type 4 3
             RRO list
           OF (optional)

            Figure 8: Adding Leaves with Full Reoptimization

   Case 2: Adding leaves with partial reoptimization of existing paths

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 1
           END-POINTS for leaf type 3
             RRO list
           END-POINTS for leaf type 4
             RRO list
           OF (optional)

            Figure 9: Adding Leaves with Partial Reoptimization

   Case 3: Adding leaves without reoptimization of existing paths

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 3 1
             RRO list
           END-POINTS for leaf type 4
             RRO list
           OF (optional)

            Figure 10: Adding Leaves without Reoptimization

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 2
             RRO list
           END-POINTS for leaf type 3
             RRO list
           OF (optional)

            Figure 11: Pruning Leaves with Full Reoptimization

  Case 5: Pruning leaves with partial reoptimization of existing paths

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 2
             RRO list
           END-POINTS for leaf type 3
             RRO list
           END-POINTS for leaf type 4
             RRO list
           OF (optional)
            Figure 12: Pruning Leaves with Partial Reoptimization

   Case 6: Pruning leaves without reoptimization of existing paths

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 2
             RRO list
           END-POINTS for leaf type 4
             RRO list
           OF (optional)

            Figure 13: Pruning Leaves without Reoptimization

   Case 7: Adding and pruning leaves full reoptimization of existing
   paths

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 1
           END-POINTS for leaf type 2
             RRO list
           END-POINTS for leaf type 3
             RRO list
           OF (optional)

            Figure 14: Adding and Pruning Leaves full Reoptimization

  Case 8: Adding and pruning leaves with partial reoptimization of
   existing paths

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 1
           END-POINTS for leaf type 2
             RRO list
           END-POINTS for leaf type 3
             RRO list
           END-POINTS for leaf type 4
             RRO list
           OF (optional)

            Figure 15: Adding and Pruning Leaves with Partial
            Reoptimization

   Case 9: Adding and pruning leaves without reoptimization of existing
   paths

           Common Header
           RP with P2MP flag/R bits set
           END-POINTS for leaf type 1
           END-POINTS for leaf type 2
             RRO list
           END-POINTS for leaf type 4
             RRO list
           OF (optional)

            Figure 16: Adding and Pruning Leaves without Reoptimization

3.11. Discovering Branch Nodes

   Before computing the P2MP path, a PCE must be provided means to know
   which nodes in the network are capable of acting as branch LSRs.  A
   PCE can discover such capabilities by using the mechanisms defined in
   [PCE-P2MP-REQ].
   [PCE-P2MP-REQ.

3.11.1 Branch Node Object

   The PCC can specify a list of nodes that can be used as branch
   nodes or a list of nodes that cannot be used as branch nodes by
   using the a BRANCH NODE Capability (BNC) Object. The BNC Object has
   the same format as the IRO object defined in [RFC5440] except that
   it only supports IPv4 and IPv6 prefix sub-objects. Two Object-
   types are also defined:

   o Branch node list: List of nodes that can be used as branch
   nodes.

   o Non-branch node list: List of nodes that cannot be used as branch
   nodes.

   The object can only be carried in a PCReq message. A Path Request
   may carry at most one BRANCH NODE Object.

   The Object-Class and Object-types will need to allocated by IANA. The
   IANA request is documented in Section 6.5.

3.12. Synchronization of P2MP TE Path Computation Requests

   There are cases when multiple P2MP LSPs' computations need to be
   synchronized.  For example, one P2MP LSP is the designated backup of
   another P2MP LSP.  In this case,  path diversity for these two dependent
   LSPs may need to be considered during the path computation.

   The synchronization can be done by just using the existing SVEC
   functionality.

   Example

   An example of synchronizing two P2MP LSPs, each has two leaves for
   Path Computation Request Messages is illustrated as below:

           Common Header
           SVEC for sync of LSP1 and LSP2
           OF (optional)
           END-POINTS1 for P2MP
            RRO1 list
           END-POINTS2 for P2MP
            RRO2 list

           Figure 17: PCReq Message Example for Synchronization

   We propose that two new flags are also added to the SVEC object for
   P2MP path dependent computation requests. The first new flag is to
   allow the PCC to request that the PCE should compute a secondary
   P2MP path tree with partial path diversity for specific leaves or
   a specific S2L sub-path to the primary P2MP path tree. The second
   flag, would allow the PCC to request that partial paths should be
   link direction diverse.

   The format of the SVEC object body is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |                   Flags             |S|N|L|P|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Request-ID-number #1                      |
   //                                                             //
   |                     Request-ID-number #M                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 19: SVEC Body Object Format with Additional Flags

 The following flags are added to the SVEC object body in this draft:

   o  P ( Partial Path Diversity bit - 1 bit):

         When set this would indicate a request for partial path
         diversity for a specific leave or set of leaves.

   o  D ( Link Direction Diverse bit - 1 bit):

        When set this would indicate a request that a partial path or
        paths should be link direction diverse.

3.13. Request and Response Fragmentation

   In certain scenarios the P2MP computation request may not fit into a
   single request or response message. For example, if a tree has many
   hundreds or thousands of leaves. Then the request or response may
   need to be fragmented into multiple messages.

   The F bit has been outlined in section 3.3.1. The the Extension of the RP
   Object, Object section
   (Section 3.3.1) of this document. The F bit is used in the RP object
   header to signal that the an initial request or response was too large
   to fit into a single message and should therefore will be fragmented into multiple requests.
   messages. In order to indentify the single request or response, each
   message will use the same request ID.

3.13.1 Request Fragmentation Procedure

   If the initial request is too large to fit into a single request
   message the PCC will split the requst request over multiple messages. Each
   message sent
   messagesent to the PCE PCE, except the last one,  will have the F bit set
   in the RP object to signify that the request has been fragmented
   into multiple messages. In order to indentify that a series of
   request messages represents a single request, each message will
   use the same request ID.

   The assumption is that request messages are reliably delivered
   and in sequence since PCEP relies on TCP.

3.13.2 Response Fragmentation Procedure

   Once the PCE computes a path based on the initial request request, a response
   is sent back to the PCC. If the response is too large to fit into a
   single response message the PCE will split the request over multiple
   messages. Each message sent to the PCE with PCE, except the last one,   will
   have the F bit set in the RP object to signify that the response
   has been fragmented into multiple messages. In order to indentify identify
   that a series of response messages represents a single request,
   each message will use the same request ID.

   The assumption is that response messages are reliably delivered
   and in sequence since PCEP relies on TCP.

3.13.3 Fragmentation Examples

  The following example illustrates the PCC sending a request message
  with Req-ID1,
  which adds Req-ID1 to the PCE, in order to add one leaf to a 1200 leaves an existing tree, is sent to the
  PCE. tree
  with 1200 leaves. The assumption is that the one request message can
  hold up to 800 leaves. In these conditions, this scenario, the original one message
  needs to be fragmented and sent over by two small messages, which
  have the Req-ID1 specified in the RP object and F bit set for the
  first message.

           Common Header
           RP1 with Req-ID1 and P2MP flag and F bit set
           OF (optional)
           END-POINTS1 for P2MP
            RRO1 list

           Common Header
           RP2 with Req-ID1 and P2MP flag and F bit cleared
           OF (optional)
           END-POINTS1 for P2MP
            RRO1 list

   To handle the case scenario that the last fragmented message piece is
   lost, the receiver side of the fragmented message may start a timer
   once it receives the first piece of the fragmented message. When
   the timer expires and it still doesn't receive has not received the last piece of the
   fragmented message, it should send an error message to the receiver sender
   to signal that it
  have has received an incomplete message.

3.14. UNREACH-DESTINATION Object

   The PCE path computation request may fail because all or a subset of
   the destinations are unreachable.

   In such a case, the UNREACH-DESTINATION object allows the PCE to
   optionally specify the list of unreachable destinations.

   This object can be present in PCRep messages.  There can be up to one
   such object per RP.

   The following UNREACH-DESTINATION objects will be required:

   UNREACH-DESTINATION Object-Class is to be assigned by IANA.
   UNREACH-DESTINATION Object-Type for IPv4 is to be assigned by IANA
   UNREACH-DESTINATION Object-Type for IPv6 is to be assigned by IANA.

   The format of the UNREACH-DESTINATION object body for IPv4 (Object-
   Type=1) is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IPv4 address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                           ...                                 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IPv4 address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 20: UNREACH-DESTINATION Object Body for IPv4

   The format of the UNREACH-DESTINATION object body for IPv6 (Object-
   Type=2) is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |            Destination IPv6 address (16 bytes)                |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          ...                                  ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |              Destination IPv6 address (16 bytes)              |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 21: UNREACH-DESTINATION Object Body for IPv6

3.15. P2MP PCEP Error Objects and Types

   To indicate errors associated with the P2MP path request, a new
   Error-Type (16) and subsequent error-values are defined as follows
   for inclusion in the PCEP-ERROR object:

   Error-Type=16 and Error-Value=1: if a PCE receives a P2MP path
   request and the PCE is not capable to satisfy the request due to
   insufficient memory, the PCE MUST send a PCErr message with a PCEP
   ERROR object (Error-Type=16) and an Error-Value(Error-Value=1).  The
   corresponding P2MP path computation request MUST also be cancelled.

   Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request
   and the PCE is not capable of P2MP computation, the PCE MUST send a
   PCErr message with a PCEP-ERROR Object (Error-Type=16) and an Error-
   Value (Error-Value=2).  The corresponding P2MP path computation
   request MUST be also cancelled.

   To indicate an error associated with policy violation, a new error
   value "P2MP Path computation not allowed" should be added to an the
   existing error code for policy violation (Error-Type=5) as defined
   in [RFC5440]:

   Error-Type=5; Error-Value=6: if a PCE receives a P2MP path
   computation request which is not compliant with administrative
   privileges (i.e., "The PCE policy does not support P2MP path
   computation"), the PCE sends MUST send a PCErr message with a PCEP-ERROR
   Object (Error-Type=5) and an Error-Value (Error-Value=6).  The
   corresponding P2MP path computation request MUST also be cancelled.

3.16. PCEP NO-PATH Indicator

   To communicate the reason(s) reasons for not being able to find P2MP path
   computation, the NO-PATH object can be used in the PCRep message.
   The format of the NO-PATH object body is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |C|        Flags                |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                      Optional TLV(s)                        //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 22:  The Format of the NO-PATH Object Body

   One new bit flags is defined in the NO-PATH-VECTOR TLV carried in
   the NO-PATH Object:

   0x20:

   0x24: when set, the PCE indicates that there is a reachability
   problem with all or a subset of the P2MP destinations.  Optionally
   the PCE can specify the destination or list of destination(s) destinations that are
   not reachable using the new UNREACH-DESTINATION object defined in
   section 3.6.

4. Manageability Considerations

   [PCE-P2MP-REQ] describes various manageability requirements in
   support of P2MP path computation when applying PCEP.  This section
   describes how manageability requirements mentioned in [PCE-P2MP-REQ]
   are supported in the context of PCEP extensions specified in this
   document.

   Note that [RFC5440] describes various manageability considerations in
   PCEP, and most of manageability requirements mentioned in [PCE-P2MP
   P2MP] are already covered there.

4.1.  Control of Function and Policy

   In addition to configuration parameters listed in [RFC5440], the
   following parameters MAY be required.

   o  P2MP path computations enabled or disabled.

   o  Advertisement of P2MP path computation capability enabled or
      disabled (discovery protocol, capability exchange).

4.2. Information and Data Models

   As described in [PCE-P2MP-REQ], MIB objects MUST be supported for
   PCEP extensions specified in this document.

4.3.  Liveness Detection and Monitoring

   There are no additional considerations beyond those expressed in
   [RFC5440], since [PCE-P2MP-REQ] does not address any additional
   requirements.

4.4.  Verifying Correct Operation

   There are no additional considerations beyond those expressed in
   [RFC5440], since [PCE-P2MP-REQ] does not address any additional
   requirements.

4.5. Requirements on Other Protocols and Functional Components

   As described in [PCE-P2MP-REQ], the PCE MUST obtain information
   about the P2MP signaling and branching capabilities of each LSR in
   the network.

   Protocol extensions specified in this document does not provide such
   capability.  Other mechanisms MUST be present.

   The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) is used to
   advertise capabilities to PCCs.  A new flag (value=10) could be
   defined in PCE-CAP-FLAGs Sub-TLV to indicate P2MP path computation
   capability. Extensions for PCE discovery are out of scope of this
   document.

4.6. Impact on Network Operation

   It is expected that use of PCEP extensions specified in this document
   does not have significant impact on network operations.

5. Security Considerations

   As described in [PCE-P2MP-REQ], P2MP path computation requests are
   more CPU-intensive and also use more link bandwidth.  Therefore, it
   may be more vulnerable to denial of service attacks. Therefore it is
   more important that implementations conform to security requirements
   of [RFC5440], and the implementor implementer utilize those security features

6. IANA Considerations

   IANA maintains a registry of PCEP parameters. A number of IANA
   considerations have been highlighted in previous sections of this
   document. In summary, IANA is requested to make
   allocations for the following PCEP parameters. allocations.

6.1 P2MP Capability TLV

   The new

   As described in Section 3.1.2, the newly defined P2MP capability TLV
   allows the PCE to advertise advertize its P2MP path computation capability. The LENGTH value is 2
   bytes.  The value field
   IANA is set requested to default value 0. make the following allocation from the "PCEP
   TLV Type Indicators" sub-registry.

   Value       Description          Reference
   6           P2MP capability      This.I-D

6.2 Request Parameter Bit Flags

   As described in Section 3.3.1., three new RP Object Functions Flags have
   been defined. IANA is requested to make the following allocations
   from the "RP Object Flag Field" Sub-Registry:

      Bit      Description                         Reference

      18       Fragmentation(F-bit)                This.I-D
      19       P2MP (N-bit)                        This.I-D
      20       ERO-compression (E-bit)             This.I-D

6.3 Objective Function Code: 7 (suggested value)
   Name: Shortest Path Tree (SPT)

   As described in Section 3.6.1., two new Objective Function Code: Funtions have been
   defined. IANA is requested to make the following allocations
   from the "Objective Function" sub-registry:

      Code Point        Name        Reference

      7                 SPT         This.I-D
      8 (suggested value)
   Name: Minimum Cost Tree (MCT)

6.3                 MCT         This.I-D

6.4 Metric Object Types

   As described in Section 3.6.2., three new metric object T fields have
   been defined. IANA is requested to make the following allocations
   from the "METRIC Object T Field" sub-reigstry:

      Value           Description               Reference

      8               P2MP IGP metric: T=8 (suggested value) metric           This.I-D
      9               P2MP TE metric: T=9 (suggested value) metric            This.I-D
      10              P2MP hop count metric: T=10 (suggested value)

6.4 UNREACH_DESTINATION metric     This.I-D

6.5 PCEP Objects

   As described in Section 3.2, 3.4 and 3.11.1, six PCE Objects

   UNREACH_DESTINATION have
   been defined. IANA is requested to make the following allocations
   from the "PCEP Objects" sub-registry

  Object-Class
   UNREACH_DESTINATION Value    25
  Name                  UNREACH-DESTINATION
  Object-Type for           1: IPv4
   UNREACH_DESTINATION Object-Type for
                        2: IPv6

6.5 P2MP
                        3-15: Unassigned
  Reference             This.I-D

  Object-Class Value    26
  Name                  SERO
  Object-Type           1: SERO
                        2-15: Unassigned
  Reference             This.I-D
  Object-Class Value    27
  Name                  SRRO
  Object-Type           1: SRRO
                        2-15: Unassigned
  Reference             This.I-D

  Object-Class Value    28
  Name                  Branch Node Capability Object
  Object-Type           1: Branch node list
                        2: Non-branch node list
                        3-15: Unassigned
  Reference             This.I-D

6.6 PCEP Error Objects and Types

   To indicate errors associated with the P2MP path request, one new
   Error-Type 5 Error-Value and two

   As described in Section 3.15., a number of new Error-Types (16) PCEP-ERROR Object
   Error Types and
   subsequent error-values will need Values have been defined. IANA is requested to be defined and included in
   make the PCEP-ERROR object:

   Error-Type=5; Error-Value=6: To indicate an error associated with
   policy violation, a new error value "P2MP following allocations from the "PCEP-ERROR Object Error
   Type and Value" sub-registry:

   Error
   Type    Meaning                                            Reference

   5      Policy violation
            Error-value=6:                                    This.I-D
              P2MP Path computation is not
   allowed".

   Error-Type=16 and allowed

   16     P2MP Error                                          This.I-D
            Error-Value=0: Unassigned
            Error-Value=1:                                    This.I-D
              The PCE is not capable to satisfy the request
              due to insufficient memory.

   Error-Type=16 and memory
            Error-Value=2:                                    This.I-D
             The PCE is not capable of P2MP
   computations.

   Additionally a new Error-Type and corresponding values will be needed
   to report reoptimization requests that fail due to END-POINT
   leaf type failures. These are:

   Error-Type=17 and computation

   17     P2MP Error                                          This.I-D
           Error-Value=0: Unassigned
           Error-Value=1:                                     This.I-D
             The PCE is not capable to satisfy the request
             due to no END-POINTS with leaf type 2.

   Error-Type=17 and 2
           Error-Value=2:                                     This.I-D
             The PCE is not capable to satisfy the request
             due to no END-POINTS with leaf type 3.

   Error-Type=17 and Error-Value=2: 3
           Error-Value=3:                                     This.I-D
             The PCE is not capable to satisfy the request
             due to no END-POINTS with leaf type 4.

6.6 SERO and SRO Object-Class

   SERO Object-Class is 25 (suggested value)

   SERO Object-Type is 1 (suggested value).

   SSRO Object-Class is 26 (suggested value).

   SSRO Object-Type 4

6.7 PCEP NO-PATH Indicator

   As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field
   has been defined. IANA is 1 (suggested value). requested to make the following
   allocation from the "NO-PATH-VECTOR TLV Flag Field" sub-registry:

      Bit    Description                               Reference

      24     P2MP Reachability Problem                This.I-D

7. Acknowledgements

   The authors would like to thank Adrian Farrel, Young Lee, Dan
   Tappan, Autumn Liu and Liu, Huaimo Chen, and Eiji Oki for their valuable
   comments on this draft.

8. References

8.1. Normative References

   [RFC5440]  Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
              A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
              "Path Computation Element (PCE) Communication Protocol
              (PCEP)", RFC 5440, March 2009.

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

   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
              "Extensions to Resource Reservation Protocol - Traffic
              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
              Switched Paths (LSPs)", RFC 4875, May 2007.

   [RFC5088]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "OSPF Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5088, January 2008.

   [RFC5089]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
              Zhang, "IS-IS Protocol Extensions for Path Computation
              Element (PCE) Discovery", RFC 5089, January 2008.

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

   [RFC5541]
              Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective
              Functions in the Path Computation Element  Communication
              Protocol (PCEP)", RFC5541, December 2008.

8.2. Informative References

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

   [PCE-P2MP-APP]
              Yasukawa, S. and A. Farrel,
              "draft-ietf-pce-p2mp-app-02.txt",
              draft-ietf-pce-p2mp-app-02 (work in progress),
              August
              October 2009.

   [PCE-P2MP-REQ]
              Yasukawa, S. and A. Farrel, "PCC-PCE Communication
              Requirements for Point to Multipoint Multiprotocol  Label
              Switching Traffic Engineering (MPLS-TE)",
              draft-ietf-pce-p2mp-req-01
              draft-ietf-pce-p2mp-req-03 (work in progress),
              February 2008.
              October 2009.

9. Authors' Addresses

   Quintin Zhao (editor)
   Huawei Technology
   125 Nagog Technology Park
   Acton, MA  01719
   US
   Email: qzhao@huawei.com

   Daniel King (editor)
   Old Dog Consulting
   UK
   Email: daniel@olddog.co.uk

   Fabien Verhaeghe
   Thales Communication France
   160 Bd Valmy 92700 Colombes
   France
   Email: fabien.verhaeghe@gmail.com

   Tomonori Takeda
   NTT Corporation
   3-9-11, Midori-Cho
   Musashino-Shi, Tokyo 180-8585
   Japan
   Email: takeda.tomonori@lab.ntt.co.jp
   Zafar Ali
   Cisco systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario  K2K 3E8
   Canada
   Email: zali@cisco.com

   Julien Meuric
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex,
   julien.meuric@orange-ftgroup.com

9.1 Contributors

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex,
   France
   Email: jeanlouis.leroux@orange-ftgroup.com

   Mohamad Chaitou
   France
   Email: mohamad.chaitou@gmail.com

Appendix A. RBNF Code Fragments

   This appendix contains the full set of code fragments defined in this
   document.

   Copyright (c) 2009 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

   o Redistributions of source code must retain the above copyright
     notice, this list of conditions and the following disclaimer.

   o Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in the
     documentation and/or other materials provided with the
     distribution.

   o Neither the name of Internet Society, IETF or IETF Trust, nor the
     names of specific contributors, may be used to endorse or promote
     products derived from this software without specific prior written
     permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

    Below is the message format for the request message:

           <PCReq Message>::= <Common Header>
                                 <request>
        where:
                <request>::= <RP>
                                <end-point-rro-pair-list>
                                [<OF>]
                                [<LSPA>]
                                [<BANDWIDTH>]
                                [<metric-list>]
                                [<IRO>]
                                [<LOAD-BALANCING>]

        where:

                <end-point-rro-pair-list>::=
                                   <END-POINTS>[<RRO-List>][<BANDWIDTH>]
                                   [<end-point-rro-pair-list>]

                <RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
                <metric-list>::=<METRIC>[<metric-list>]

    Below is the message format for the reply message:

       Below is the message format for the reply message:

          <PCRep Message>::= <Common Header>
                                <response>
          <response>::=<RP>
                          [<end-point-path-pair-list>]
                          [<NO-PATH>]
                          [<attribute-list>]

        where:

           <end-point-path-pair-list>::=
                   [<END-POINTS>]<path>[<end-point-path-pair-list>]

          <path> ::=(ERO)|(SERO)|<path>]

          <attribute-list>::=[<OF>]
                               [<LSPA>]
                               [<BANDWIDTH>]
                               [<metric-list>]
                               [<IRO>]