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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6006

Internet Engineering Task Force                             Q. Zhao, Ed.
Internet-Draft                                         Huawei Technology
Intended Status: Standards Track                        Daniel King, Ed.
Expires: November 25, 2010                            Old Dog Consulting
                                                            May 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-11.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 May 25, 2010.






Zhao, King, et al.                                             [Page 1]

Internet-Draft                                                May 2010


Copyright Notice

   Copyright (c) 2010 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.

   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.

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 . . . . . . . . . . . . . . . . . . . . . . . . .3
     1.1 Terminology  . . . . . . . . . . . . . . . . . . . . . . . .4
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .5
   3.  Protocol Procedures and Extensions . . . . . . . . . . . . . .6
     3.1.  P2MP Capability Advertisement  . . . . . . . . . . . . . .6
       3.1.1.  P2MP Computation TLV in the Existing PCE Discovery
               Protocol . . . . . . . . . . . . . . . . . . . . . . .6
       3.1.2.  Open Message Extension . . . . . . . . . . . . . . . .6
     3.2.  Efficient Presentation of P2MP TE LSPs . . . . . . . . . .7
     3.3.  P2MP Path Computation Request/Reply Message Extensions . .8
       3.3.1.  The Extension of the RP Object . . . . . . . . . . . .8
       3.3.2.  The New P2MP END-POINTS Object . . . . . . . . . . . .9
     3.4.  Request Message Format . . . . . . . . . . . . . . . . . .11
     3.5.  Reply Message Format . . . . . . . . . . . . . . . . . . .11
     3.6.  P2MP Objective Functions and Metric Types  . . . . . . . .12


Zhao, King, et al.                                             [Page 2]

Internet-Draft                                                May 2010


       3.6.1.  New Objective 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 Reoptimization Request  . . . . . . . . . . .14
     3.10. Adding and Pruning Leaves to the P2MP Tree . . . . . . . .14
     3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . .17
       3.11.1 Branch Node Object . . . . . .  . . . . . . . . . . . .17
     3.12. Synchronization of P2MP TE Path Computation Requests . . .18
     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 and Types . . . . . . . . . . . . .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  . . . . . . . . . . . . . . .24
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .24
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .24
     6.1.  PCEP TLV Type Indicators . . . . . . . . . . . . . . . . .25
     6.2.  Request Parameter Bit Flags  . . . . . . . . . . . . . . .25
     6.3.  Objective Functions  . . . . . . . . . . . . . . . . . . .25
     6.4.  Metric Object Types  . . . . . . . . . . . . . . . . . . .25
     6.5.  PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .25
     6.6.  PCEP Error Objects and Types . . . . . . . . . . . . . . .26
     6.7.  PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .27
     6.8.   SVEC Object Flag  . . . . . . . . . . . . . . . . . . . .27
     6.9.   OSPF PCE Capability Flag . . . . . . . .  . . . . . . . .28
   7.  Acknowledgement's  . . . . . . . . . . . . . . . . . . . . . .28
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .28
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .28
     8.2.  Informative References . . . . . . . . . . . . . . . . . .29
   9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .30
     9.1.  Contributors . . . . . . . . . . . . . . . . . . . . . . .31


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.

Zhao, King, et al.                                             [Page 3]

Internet-Draft                                                May 2010


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

   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.

   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 overlaid to construct a P2MP TE LSP. During path
   computation, the P2MP TE LSP may be determined as a set of S2L sub-
   LSPs that are computed separately and combined to give the path of
   the P2MP LSP, or the entire P2MP TE LSP may be determined as a P2MP
   tree in a single computation.

   This document relies on the mechanisms of PCEP to request path
   computation for P2MP TE LSPs.  One path computation request message
   from a PCC may request the computation of the whole P2MP TE LSP, or
   the request may be limited to a sub-set of the S2L sub-LSPs. In the
   extreme case, the PCC may request the S2L sub-LSPs to be computed
   individually with it being the PCC's responsibility to decide whether
   to signal individual S2L sub-LSPs or combine the computation results
   to signal the entire P2MP TE LSP.  Hence the PCC may use one path
   computation request message or may split the request across multiple
   path computation messages.

1.1  Terminology

   Terminology used in this document.

   TE LSP: Traffic Engineered Label Switched Path.

   LSR: Label Switching Router.

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

   P2MP: Point-to-Multipoint.

   P2P: Point-to-Point.



Zhao, King, et al.                                             [Page 4]

Internet-Draft                                                May 2010


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


2.  Requirements

   This section summarizes the PCC-PCE Communication Requirements for
   P2MP MPLS-TE LSPs described in [PCE-P2MP-REQ]. The numbering system
   corresponds to the requirement numbers used in [PCE-P2MP-REQ].

   1. The PCC MUST be able to specify that the request is a P2MP path
      computation request.

   2. The PCC MUST be able to specify that objective functions are to be
      applied to the P2MP path computation request.

   3. The PCE MUST have the capability to reject a P2MP path request
      and indicate non-support of P2MP path computation.

   4. The PCE MUST provide an indication of non-support of P2MP path
      computation by back-level PCE implementations.

   5. A P2MP path computation request MUST be able to list multiple
      destinations.

   6. A P2MP path computation response MUST be able to carry the path
      of a P2MP LSP.

   7. It MUST be possible for a single P2MP path computation request or
      response to be conveyed by a sequence of messages.

   8. It MUST NOT be possible for a single P2MP path computation
      request to specify a set of different constraints, traffic
      parameters, or quality-of-service requirements for different
      destinations of a P2MP LSP.

   9. P2MP path modification and P2MP path diverse MUST be supported.

   10. It MUST be possible to reoptimize existing P2MP TE LSPs.

   11. It MUST be possible to add and remove P2MP destinations
       from existing paths.

   12. It MUST be possible to specify a list of applicable branch
       nodes to use when computing the P2MP path.

   13. It MUST be possible for a PCC to discover P2MP path computation
       capability.



Zhao, King, et al.                                             [Page 5]

Internet-Draft                                                May 2010


   14. The PCC MUST be able to request diverse paths when requesting a
       P2MP path.


3.  Protocol Procedures and Extensions

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

3.1.  P2MP Capability Advertisement

3.1.1.  P2MP Computation TLV in the Existing PCE Discovery Protocol

   [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF
   Router Information LSA defined in [RFC4970] to facilitate PCE
   discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be
   added to the PCED TLV. This document defines a new flag in the OSPF
   PCE Capability Flags to indicate the capability of P2MP computation.

   Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE
   Discovery using IS-IS. This document will use the same flag
   requested for the OSPF PCE Capability Flags sub-TLV
   to allow IS-IS to indicate the capability of P2MP computation.

   The IANA request for a shared OSPF and IS-IS P2MP capability flag
   is documented in Section 6.9. (OSPF PCE Capability Flag) of this
   document.

   PCEs wishing to advertise that they support P2MP path computation
   would set the bit (to be assigned by IANA) accordingly. PCCs that
   do not understand this bit will ignore it (per [RFC5088] and
   [RFC5089]). PCEs that do not support P2MP will leave the bit clear
   (per the default behavior defined in [RFC5088] and [RFC5089]).

   PCEs that set the bit to indicate support of P2MP path computation
   MUST follow the procedures in Section 3.1.2. (The New P2MP END-POINTS
   Object)to further qualify the level of support

3.1.2.  Open Message Extension

   Based on the Capabilities Exchange requirement described in
   [PCE-P2MP-REQ]. If a PCE does not advertise its P2MP capability
   during discovery, PCEP should be used to allow a PCC to discover
   during the Open Message Exchange, which PCEs are capable of
   supporting P2MP path computation.

   To satisfy this requirement, we extend the PCEP OPEN object by
   defining a new optional TLV to indicate the PCE's capability to
   perform P2MP path computations.

Zhao, King, et al.                                             [Page 6]

Internet-Draft                                                May 2010


   The allocation from the "PCEP TLV Type Indicators" sub-registry will
   be assigned by IANA and the request is documented in Section 6.1.
   (PCEP TLV Type Indicators). The description is "P2MP capable", the
   length value is 2 bytes. The value field is set to default value 0.

   The inclusion of this TLV in an OPEN object indicates that the sender
   can perform P2MP path computations.

   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.  Efficient Presentation of P2MP LSPs

   When specifying additional leaves, or optimizing existing P2MP TE
   LSPs as specified in [PCE-P2MP-REQ], 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 Reservation Protocol Traffic Engineering
   Extensions (RSVP-TE) Explicit Route Object (ERO) to encode the
   explicit route of a TE LSP through the network.  PCEP ERO sub-object
   types correspond to RSVP-TE ERO sub-object types. The format and
   content of the ERO object are defined in [RFC3209] and [RFC3473].

   The Secondary Explicit Route Object (SERO) is used to specify the
   explicit route of a S2L sub-LSP.  The path of each subsequent S2L
   sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO.
   The format of the SERO is the same as an ERO defined in [RFC3209]
   and [RFC3473].

   The Secondary Recorded Route Object (SRRO) is used to record
   the explicit route of the S2L sub-LSP. The class of the P2MP SRRO
   is the same as the SRRO defined in [RFC4873].

   The SERO and SRRO are used to report the route of an existing TE
   LSP for which a reoptimization is desired. The format and content
   of the SERO and SRRO are defined in [RFC4875].

   A new PCEP object class and type are requested for SERO and SRRO.

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

Zhao, King, et al.                                             [Page 7]

Internet-Draft                                                May 2010


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

   The IANA request is referenced in Section 6.5. (PCEP Objects).

   Since the explicit path is available for immediate signaling by the
   MPLS or GMPLS control plane, the meanings of all of the sub-objects
   and fields in this object are identical to those defined for the ERO.

3.3.  P2MP Path Computation Request/Reply Message Extensions

   This document extends the existing P2P RP (Request Parameters) object
   so that a PCC can signal a P2MP path computation request to the PCE
   receiving the PCEP request.  The END-POINT object is also 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 parameters to allow a receiving PCE to
   identify that the request and reply message has been fragmented
   across multiple messages, has been requested for a P2MP path and to
   specify if the route is represented in the compressed or uncompressed
   format.

   This document adds the following flags to the RP Object:

   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.

   o  F ( RP fragmentation bit - 1 bit):

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

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

   The N 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.



Zhao, King, et al.                                             [Page 8]

Internet-Draft                                                May 2010


   o  N ( P2MP bit - 1 bit):

         0: This indicates that this is not PCReq/PCRep for P2MP.

         1: This indicates that this is PCReq or PCRep message for P2MP.

   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 compressed
   format or not. By default, the path returned by the PCE will use the
   compressed format.

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

         0: This indicates that the route is not in the compressed
         format.

         1: This indicates that the route is in the compressed format.

   The IANA request is referenced in Section 6.2 (Request Parameter Bit
   Flags) of this document.

3.3.2.  The New P2MP END-POINTS Object

   The END-POINTS object is used in a PCReq message to specify the
   source IP address and the destination IP address of the path for
   which a path computation is requested. To represent the end points
   for a P2MP path efficiently, we define two new types of end-point
   objects for the P2MP path:

   o  Old leaves whose path can be modified/reoptimized;
   o  Old leaves whose path must be left unchanged.

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

   In total there are now 4 possible types of leaves in a P2MP request:

   o New leaves to add (leaf type = 1)
   o Old leaves to remove (leaf type = 2)
   o Old leaves whose path can be modified/reoptimized (leaf type = 3)
   o Old leaves whose path must be left unchanged (leaf type = 4)

   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.

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

Zhao, King, et al.                                             [Page 9]

Internet-Draft                                                May 2010


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

   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 1: 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 2: The New P2MP END-POINTS Object Body Format for IPv6


Zhao, King, et al.                                            [Page 10]

Internet-Draft                                                May 2010


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

3.4.  Request Message Format

   The PCReq message is encoded as follows using RBNF as defined in
   [RFC5511].

   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 3: 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 message.

   We have documented the IANA request for additional END-POINTS
   Object-Types in Section 6.5 (PCEP Objects) of this document.

3.5.  Reply Message Format

   The PCRep message is encoded as follows using RBNF as defined in
   [RFC5511].

   Below is the message format for the reply message:




Zhao, King, et al.                                            [Page 11]

Internet-Draft                                                May 2010


          <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 4: 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 E bit (ERO-Compress bit) was set to 1 in the request then the
   path will be formed by an ERO followed by a list of SEROs.

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

3.6. P2MP Objective Functions and Metric Types

3.6.1.  New Objective 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)

Zhao, King, et al.                                            [Page 12]

Internet-Draft                                                May 2010


   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 additional types for the <METRIC> object: the
   P2MP IGP metric, the P2MP TE metric, and the P2MP 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 request MUST then be
      cancelled at the PCC. New Error-Types and Error-Values are
      requested in Section 6. (IANA Considerations) 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 Error-value=2
      (capability not supported).

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

   If a PCE receives a P2MP request and the PCE does not understand the
   P2MP flag in the RP object, and therefore the PCEP P2MP extensions,
   then the PCE SHOULD reject the request.

Zhao, King, et al.                                            [Page 13]

Internet-Draft                                                May 2010


3.9.  P2MP TE Path Reoptimization Request

   A reoptimization request for a P2MP TE path is specified by the use
   of the R bit within the RP object as defined in [RFC5440] and is
   similar to the reoptimization request for a P2P TE path.  The only
   difference is that the user MUST insert the list of RROs and SRROs
   after each type of END-POINTS in the PCReq 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
   is described below:

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

            Figure 5: PCReq Message Example 1 for Optimization

   In this example, we request reoptimization of the path to all leaves
   without adding or pruning leaves.  The reoptimization request would
   use an END-POINT type 3. The RRO list would represent the P2MP LSP
   before the optimization and the modifiable path leaves would be
   indicated in the END-POINTS object.

   It is also possible to specify specific leaves whose path cannot
   be modified.  An example of the PCReq message in this scenario would
   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 6: PCReq Message Example 2 for Optimization

3.10.  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, it SHOULD be possible
   to optimize the existing P2MP tree. This section explains 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 using
   END-POINTS with leaf type 1.


Zhao, King, et al.                                            [Page 14]

Internet-Draft                                                May 2010


   To remove old leaves the user must build a P2MP request using
   END-POINTS with leaf type 2. If no type-2 end-points exist, then the
   PCE MUST send an error type 17, value=1: The PCE is not capable to
   satisfy the request due to no END-POINTS with leaf type 2.

   The PCC must also provide the list of old leaves, if any, including
   END-POINTS with leaf type 3, leaf type 4 or both.  The error values
   when the 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). A generic "Inconsistent END-POINT" error is also
   requested if a PCC receives a request that has an inconsistent
   END-POINT (i.e.,  if a leaf specified as type 1 already exists). The
   The IANA request for all new error values is documented in Section
   6.6. (PCEP Error Objects and Types) of this document.

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

   The following examples demonstrate full and partial reoptimization
   of existing P2MP 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 1
             RRO list
           END-POINTS for leaf type 3
             RRO list
           OF (optional)

   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)

   Case 3: Adding leaves without reoptimization of existing paths







Zhao, King, et al.                                            [Page 15]

Internet-Draft                                                May 2010


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


   Case 4: Pruning Leaves with Full 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)

    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)

   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)

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








Zhao, King, et al.                                            [Page 16]

Internet-Draft                                                May 2010


           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)

   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)

   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)

3.11. Discovering Branch Nodes

   Before computing the P2MP path, a PCE may need to 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 [RFC5073].

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:

Zhao, King, et al.                                            [Page 17]

Internet-Draft                                                May 2010


   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. (PCEP Objects).

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 diverse for these dependent
   LSPs may need to be considered during the path computation.

   The synchronization can be done by using the existing SVEC
   functionality defined in [RFC5440]

   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 7: PCReq Message Example for Synchronization

   This specification also defines two new flags to the SVEC Object Flag
   Field 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 diverse 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 following flags are added to the SVEC object body in this
   document:

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

        When set this would indicate a request for path diverse
        for a specific leaf, a set of leaves or all leaves.

Zhao, King, et al.                                            [Page 18]

Internet-Draft                                                May 2010


   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.

   The IANA request is referenced in Section 6.8. of this document.

3.13. Request and Response Fragmentation

   The total PCEP message-length, including the common header, is 16
   bytes. 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 the Extension of the RP Object section
   (Section 3.3.1) of this document. The F bit is used in the RP object
   header to signal that the initial request or response was too large
   to fit into a single message and will be fragmented into multiple
   messages. In order to identify 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 request over multiple messages. Each
   message sent to the 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 identify 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, 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 response over multiple
   messages. Each message sent to the 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 identify
   that a series of response messages represents a single response,
   each message will use the same response ID.

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

3.13.3 Fragmentation Examples

Zhao, King, et al.                                            [Page 19]

Internet-Draft                                                May 2010


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

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

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

           Figure 8: PCReq Message Fragmentation Example

   To handle the 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 has not received the last piece of the
   fragmented message, it should send an error message to the sender
   to signal that it has received an incomplete message. The relevant
   error message is document in Section 3.15. (P2MP PCEP Error Objects
   and Types).

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.



Zhao, King, et al.                                            [Page 20]

Internet-Draft                                                May 2010


   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 9: 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 10: UNREACH-DESTINATION Object Body for IPv6


3.15. P2MP PCEP Error Objects and Types

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

   Error-Type=5; Error-Value=7: 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 MUST send a PCErr message with a PCEP-ERROR
   Object (Error-Type=5) and an Error-Value (Error-Value=7).  The
   corresponding P2MP path computation request MUST also be cancelled.

Zhao, King, et al.                                            [Page 21]

Internet-Draft                                                May 2010

   To indicate capability 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 P2MP message fragmentation errors associated with a P2MP
   path request, a new Error-Type (17) and subsequent error-values are
   defined as follows for inclusion in the PCEP-ERROR object:

   Error-Type=18; Error-Value=1: if a PCE has not received the last
   piece of the fragmented message, it should send an error message
   to the sender to signal that it has received an incomplete message
   (i.e., "Fragmented request failure"), the PCE MUST send a PCErr
   message with a PCEP-ERROR Object (Error-Type=18) and an Error-Value
   (Error-Value=1).

3.16. PCEP NO-PATH Indicator

   To communicate the reasons for not being able to find P2MP path
   computation, the NO-PATH object can be used in the PCRep message.

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

   bit 24: 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 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.


Zhao, King, et al.                                            [Page 22]

Internet-Draft                                                May 2010


   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 PCE configuration parameters listed in [RFC5440],
   the following additional parameters might be required:

   o  The ability to enable to disable P2MP path computations on the
      PCE.

   o  The PCE may be configured to enable or disable the advertizement
      of its P2MP path computation capability. A PCE can advertize its
      P2MP capability via the IGP discovery mechanism discussed in
      Section 3.1.1. (P2MP Computation TLV in the Existing PCE Discovery
      Protocol), or during the Open Message Exchange discussed in
      Section 3.1.2. (Open Message Extension).

4.2. Information and Data Models

   A number of MIB objects have been defined for general PCEP control
   and monitoring of P2P computations in [PCEP-MIB]. [PCE-P2MP-REQ]
   specifies that MIB objects will be required to support the control
   and monitoring of the protocol extensions defined in this document.
   A new document will be required to define MIB objects for PCEP
   control and monitoring of P2MP computations.

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 requirements beyond those expressed in
   [RFC4657] for verifying the correct operation of the PCEP sessions.
   It is expected that future MIB objects will facilitate verification
   of correct operation and reporting of P2MP PCEP requests, responses
   and errors.

4.5. Requirements on Other Protocols and Functional Components

   The method for the PCE to obtain information about a PCE capable of
   P2MP path computations via OSPF and IS-IS is discussed in Section
   3.1.1 (P2MP Computation TLV in the Existing PCE Discovery Protocol)
   of this document.



Zhao, King, et al.                                            [Page 23]

Internet-Draft                                                May 2010


   The subsequent IANA requests are documented in Section 6.9 (PCE
   Capability Flag) of this document.

4.6. Impact on Network Operation

   It is expected that use of PCEP extensions specified in this document
   will not significantly increase the level of operational traffic.
   However, computing a P2MP tree may require more PCE state compared to
   a P2P computation. In the event of a major network failure and
   multiple recovery P2MP tree computation requests being sent to the
   PCE, the load on the PCE may also be significantly increased.


5. Security Considerations

   As described in [PCE-P2MP-REQ], P2MP path computation requests are
   more CPU-intensive and also utilize more link bandwidth. In the
   event of an unauthorized P2MP path computation request, or denial of
   service attack, the subsequent PCEP requests and processing may be
   disruptive to the network. Consequently, it is important that
   implementations conform to the relevant security requirements of
   [RFC5440] that specifically help to minimize or negate unauthorized
   P2MP path computation requests and denial of service attacks. These
   mechanisms include:

   o Securing the PCEP session requests and responses using TCP Security
     Techniques (Section 10.2. [RFC5440]).

   o Authenticating the PCEP requests and responses to ensure the
     message is intact and sent from an authorized node (Section 10.3.
     [RFC5440]).

   o Providing policy control by explicitly defining which PCCs, via IP
     access-lists, are allowed to send P2MP path requests to the PCE
     (Section 10.6. [RFC5440]).

   PCEP operates over TCP so it is also important to secure the PCE and
   PCC against TCP denial of service attacks. Section 10.7.1 of
   [RFC5440] outlines a number of mechanisms for minimizing the risk of
   TCP based denial of service attacks against PCEs and PCCs.

   PCEP implementations SHOULD consider the additional security provided
   by TCP-AO [TCP-AUTH].


6. IANA Considerations

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

Zhao, King, et al.                                            [Page 24]

Internet-Draft                                                May 2010


6.1 PCEP TLV Type Indicators

   As described in Section 3.1.2., the newly defined P2MP capability TLV
   allows the PCE to advertize its P2MP path computation capability.
   IANA is requested to make the following allocation from the "PCEP
   TLV Type Indicators" sub-registry.

   Value       Description          Reference
   6           P2MP capable         This.I-D

6.2 Request Parameter Bit Flags

   As described in Section 3.3.1., three new RP Object Flags have
   been defined. IANA is requested to make the following allocations
   from the "PCEP 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 Functions

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

      Code Point        Name        Reference

      7                 SPT         This.I-D
      8                 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 "PCEP METRIC Object T Field" sub-registry:

      Value           Description               Reference

      8               P2MP IGP metric           This.I-D
      9               P2MP TE metric            This.I-D
      10              P2MP hop count metric     This.I-D

6.5 PCEP Objects

   As discussed in Section 3.3.2., two new END-POINTS Object-Types are
   defined. IANA is requested to make the following Object-Type
   allocations from the "PCEP Objects" sub-registry:

Zhao, King, et al.                                            [Page 25]

Internet-Draft                                                May 2010


      Object-Class Value    4
      Name                  END-POINTS
      Object-Type           3: IPv4
                            4: IPv6
                            5-15: Unassigned
      Reference             This.I-D

   As described in Section 3.2., Section 3.11.1. and Section 3.14.,
   four PCEP Object-Classes and six PCEP Object-Types have been defined.
   IANA is requested to make the following allocations from the "PCEP
   Objects" sub-registry:

      Object-Class Value    28
      Name                  UNREACH-DESTINATION
      Object-Type           1: IPv4
                            2: IPv6
                            3-15: Unassigned
      Reference             This.I-D

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

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

      Object-Class Value    31
      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

   As described in Section 3.15., a number of new PCEP-ERROR Object
   Error Types and Values have been defined. IANA is requested to
   make the following allocations from the "PCEP PCEP-ERROR Object
   Error Type and Value" sub-registry:

   Error
   Type    Meaning                                            Reference

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

Zhao, King, et al.                                            [Page 26]

Internet-Draft                                                May 2010


   16     P2MP Capability 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-Value=2:                                    This.I-D
             The PCE is not capable of P2MP computation

   17     P2MP END-POINTS 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-Value=2:                                     This.I-D
             The PCE is not capable to satisfy the request
             due to no END-POINTS with leaf type 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
           Error-Value=4:                                     This.I-D
             The PCE is not capable to satisfy the request
             due to inconsistent END-POINTS

   18    P2MP Fragmentation Error                             This.I-D
           Error-Value=0: Unassigned
           Error-Value=1:                                     This.I-D
             Fragmented request failure


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 requested to make the following
   allocation from the "PCEP NO-PATH-VECTOR TLV Flag Field"
   sub-registry:

      Bit    Description                               Reference

      24     P2MP Reachability Problem                 This.I-D


6.8 SVEC Object Flag

    As discussed in Section 3.12, two new SVEC Object Flags are
    defined. IANA is requested to make the following
    allocation from the "PCEP SVEC Object Flag Field" sub-registry:




Zhao, King, et al.                                            [Page 27]

Internet-Draft                                                May 2010


      Bit      Description                              Reference

      19       Partial Path Diverse                     This.I-D
      20       Link Direction Diverse                   This.I-D

6.9 PCE Capability Flag

   As discussed in Section 3.1, a new OSPF Capability Flag is defined
   to indicate P2MP path computation capability. IANA is requested to
   make the assignment from the "OSPF Parameters Path Computation
   Element (PCE) Capability Flags" registry:

      Bit      Description                              Reference

      10       P2MP path computation                    This.I-D


7. Acknowledgements

   The authors would like to thank Adrian Farrel, Young Lee, Dan
   Tappan, Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh
   Babu K,Dhruv Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas
   Manral, Dan Romascanu, Tim Polk, Stewart Bryant, David
   Harrington and Sean Turner for their valuable comments and input
   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.

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

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
              "GMPLS Segment Recovery", RFC 4873, May 2007


Zhao, King, et al.                                            [Page 28]

Internet-Draft                                                May 2010


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

   [RFC4970]  Lindem A., et al.
              "Extensions to OSPF for Advertising Optional Router
              Capabilities', RFC 4970, July 2007

   [RFC5073]  Vasseur, JP., Le Roux, JL., "IGP Routing Protocol
              Extensions for Discovery of Traffic Engineering Node
              Capabilities", RFC 5073, December 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.

   [RFC5671]  Yasukawa, S. and A. Farrel, "Applicability of the Path
              Computation Element (PCE) to Point-to-Multipoint (P2MP)
              MPLS and GMPLS Traffic Engineering (TE)" RFC 5671,
              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-05 (work in progress),
              December 2009.

   [PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., and King, D.,
              "PCE communication protocol(PCEP) Management
              Information Base", draft-ietf-pce-pcep-mib-01 (work in
              progress), March 2010.

Zhao, King, et al.                                            [Page 29]

Internet-Draft                                                May 2010


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

   [TCP-AUTH] Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", draft-ietf-tcpm-tcp-auth-opt-11
              (work in progress), March 2010.


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

Zhao, King, et al.                                            [Page 30]

Internet-Draft                                                May 2010


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







































Zhao, King, et al.                                            [Page 31]
Internet-Draft                                                May 2010

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/