Internet Engineering Task Force                             Q. Zhao, Ed.
Internet-Draft                                         Huawei Technology
Intended Status: Standards Track                        Fabien Verhaeghe
Created: March 8, 2009                                   Marben Products
Expires: September 8, 2009                             Daniel King
Expires: January 12, 2009                             Old Dog Consulting
                                                           July 12, 2009

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

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 December 6, 2009.

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
   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 . . . . . . . . . . . . . . . . . . . . . . . . .
     1.1 Terminology  . . . . . . . . . . . . . . . . . . . . . . . .
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .
   3.  Protocol Procedures and Extensions . . . . . . . . . . . . . .
     3.1.  P2MP Capability Advertisement  . . . . . . . . . . . . . .
       3.1.1.  Extend the TLV in the Existing PCE Discovery
               Protocol . . . . . . . . . . . . . . . . . . . . . . .
       3.1.2.  Open Message Extension . . . . . . . . . . . . . . . .

     3.2.  P2MP LSPs Efficient Presentation . . . . . . . . . . . . .
     3.3.  Indication of P2MP Path Computation Request/Reply  . . . .
       3.3.1.  The Extension of RP Object . . . . . . . . . . . . . .
       3.3.2.  The New P2MP END-POINTS Object . . . . . . . . . . . .
     3.4.  Request Message Formats  . . . . . . . . . . . . . . . . .
     3.5.  Reply Message Formats  . . . . . . . . . . . . . . . . . .
     3.6.  P2MP Objective Functions and Metric Types  . . . . . . . .
       3.6.1.  New Object Functions . . . . . . . . . . . . . . . . .
       3.6.2.  New Metric Object Types  . . . . . . . . . . . . . . .
     3.7.  Non-Support of P2MP Path Computation.  . . . . . . . . . .
     3.8.  Non-Support by Back-Level PCE Implementations. . . . . . .
     3.9.  P2MP TE Path Re-optimization Request . . . . . . . . . . .
     3.10. Adding/pruning Leaves  . . . . . . . . . . . . . . . . . .
     3.11. Branch Nodes . . . . . . . . . . . . . . . . . . . . . . .
     3.12. Synchronization of P2MP TE Path Computation Requests . . .
     3.13. Multi-Message Support Request and Response Fragmentation . . . . . . . . . . . .
       3.13.1 Request Fragmentation Procedure . . . . . . . . . . . .
       3.13.2 Response Fragmentation Procedure  . . . . . . . . . . .
       3.13.3 Fragmentation Examples  . . . . . . . . . . . . . . . .
     3.14. UNREACH_DESTINATION object . . . . . . . . . . . . . . . .
     3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . .
     3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .
   4.  Manageability Considerations . . . . . . . . . . . . . . . . .
     4.1.  Control of Function and Policy . . . . . . . . . . . . . .
     4.2.  Information and Data Models  . . . . . . . . . . . . . . .
     4.3.  Liveness Detection and Monitoring  . . . . . . . . . . . .
     4.4.  Verifying Correct Operation  . . . . . . . . . . . . . . .
     4.5.  Requirements on Other Protocols and Functional
           Components . . . . . . . . . . . . . . . . . . . . . . . .
     4.6.  Impact on Network Operation  . . . . . . . . . . . . . . .
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .
   7.  Acknowledgement  . .
     6.1   New Object Functions . . . . . . . . . . . . . . . . . . .
     6.2   New Metric Object Types  . . . . . . . . . . . . . . . . .
     5.3   UNREACH_DESTINATION objects  . . . . . . . . . . . . . . .
   7.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . .
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .
     8.2.  Informative References . . . . . . . . . . . . . . . . . .
   9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .
     9.1.  Contributors   . . . . . . . . . . . . . . . . . . . . . .
   10. Intellectual Property Consideration. . . . . . . . . . . . . .
   11. Disclaimer of Validity . . . . . . . . . . . . . . . . . . . .
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . .

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 is 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 semantics 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 result from PCE to result in 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].

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

2. Requirements

   This section summarizes the PCEP requirements specific to Point to
   Multipoint as described in [PCE-P2MP-REQ].

   R1: Indication of P2MP Path Computation Request.

   R2: Indication of P2MP Objective Functions.

   R3: Non-Support of P2MP Path Computation.

   R4: Non-Support by Back-Level PCE Implementations.

   R5: Specification of Destinations.

   R6: Indication of P2MP Paths.

   R7: Multi-Message Requests and Responses.

   R8: Non-Specification of Per-Destination Constraints and Parameters.

   R9: Path Modification and Path Diversity.

   R10: Reoptimization of P2MP TE LSPs.

   R11: Addition and Removal of Destinations from Existing Paths.

   R12: Specification of Applicable Branch Nodes.

   R13: Capabilities Exchange.

   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.

3. Protocol Procedures and Extensions

   The following sections describe the protocol extensions to satisfy
   the requirements specified in the previous section.

3.1. P2MP Capability Advertisement

3.1.1. Extend the TLV in the Existing PCE Discovery Protocol

   Since the [RFC5088] has specified that we can not add additional sub-
   TLV to the PCED TLV, we will define new bits to go in the existing 32
   bits PCE Caps Flags to indicate the capability of P2MP for the PCC
   and PCE.

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 through
   discovery and the capability is not configured to the PCC, we need to
   use PCEP to allow a PCC to discover which PCEs with which it
   communicates support 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 path
   computation capabilities.

   The TLV type number will be assigned by IANA, 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 capability.

3.2. P2MP LSPs Efficient Presentation

   In the request message of the adding of leaves, optimization of P2MP
   TE LSPs as specified in [PCE-P2MP-REQ], and in the reply message, we
   need to pass an existing P2MP LSP between the PCC and PCE.  In these
   cases, we need new path objects for efficiently passing the existing
   P2MP LSP between PCE to PCC.

   We suggest to using the ERO/SERO and RRO/SRRO to represent each
   individual S2L sub-LSP.  The contents of ERO/RRO are same as defined
   in the [RFC5440] and the contents of SERO and SRRO are same as
   defined in RFC4875 for the RSVP extension of P2MP except we need
   assign the new class and type for all of them.

3.3. Indication of P2MP Path Computation Request/Reply

   The existing P2P RP object is extended so that it can signal to the
   receiver of the request or reply message 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 RP Object

   The PCE path computation request/reply message adds an explicit
   parameter to allow a receiving PCE to identify that the request/reply
   is for a P2MP path and also to specify if the route is represented in
   the compress format or not.

   The F bit

   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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Reserved   | Flags           |E|M|              O|B|R|         |F|E|M|             |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 ( P2MP bit - 1 bit):

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

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

   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.

   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 and the receiver
             need to wait until it receives an RP with the same RP-ID
             and with the F bit is set to 0.

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 P2MP path.

   With this new END-POINTS object, the PCE path computation request
   message is expanded in a way such that it 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 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 new END-POINTS object, the END-POINTS portions of a request
   message for the multiple destinations can be roughly reduced up to
   50% for a P2MP path where a single source address has a very large
   number of destinations.

   Note that A P2MP path computation request can mix the different type
   of leaves by including several END-POINTS object per RP object as
   shown in PCReq BNF format in next section.

   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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          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 of 4
   bytes for IPv4 and multiple of 16 bytes for IPv6.

3.4. Request Message Formats

   As per [RFC5511] the 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 with P2MP flag and ERO-Compress bit> <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-POINTS>[<RRO-List>][<BANDWIDTH>]
                                   [<end-point-rro-pair-list>]

                RRO-List::=<RRO>[BANDWIDTH][<RRO 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

   As per [RFC5511] the 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 with P2MP flag and ERO-Compress bit>
          <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>] ::=(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 request then the path will be
   formed by an ERO followed by a list of SERO.  Otherwise it is a list
   of ERO.

3.6. P2MP Objective Functions and Metric

   Note 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 [PCE-OF] [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 [PCE-OF]. [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 metric.  They
   encode the sum of the metrics of all links of the tree.  We propose
   the following values for these new metric types (to be assigned by
   IANA):

   o  P2MP IGP metric: T=4

   o  P2MP TE metric: T=5

   o  P2MP hop count metric: T=6

3.7.  Non-Support of P2MP Path Computation.

   o  if a PCE receives a P2MP path request and it understands the P2MP
      flag in RP object, but the PCE is not capable of P2MP computation,
      the PCE MUST send a PCErr message with a PCEP-ERROR Object and an
      Error-Value.  The corresponding P2MP path computation request MUST
      be cancelled.  (Error-Type and Error-Value are defined in 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 we accidentally send the P2MP request to a PCE which does not
   support the PCEP P2MP extensions yet, then it will reject the request
   because it cannot understand the new END-POINTS object.

3.9.  P2MP TE Path Re-optimization Request

   The re-optimization request for a P2MP TE path is specified by R bit
   in the RP object similarly to the re-optimization request for a P2P
   TE path.  The only difference is that the user must insert the list
   of RRO after each type of END-POINTS as described in the PCReq
   message format section.

   So the PCReq message would look like this:

           <PCReq Message>::= <Common Header>
                           <request>

               where:

                   <request>::=<RP

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

            Figure 6: PCReq Message Example 1 for Optimization

   In this example, we request re-optimization 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 leaves whose path cannot be
   modified.  The PCReq message would then look like this:

           <PCReq Message>::= <Common Header>
                           <request>

               where:

                   <request>::=<RP

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

            Figure 7: PCReq Message Example 2 for Optimization

3.10.  Adding/pruning Leaves

   When adding new leaves or removing old leaves to the existing P2MP
   tree, by supplying a list of existing leaves, one may be able to
   optimize the new P2MP tree.  This section explains ways 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 must also provides the list of old leaves and indicate
   if they must be reoptimized or not by including END-POINTS with leaf
   type 3 or 4 or both.  In the future version, we may want to consider
   to define error values when the condition is 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).

   For old leaves the user must provide the old path as list of RROs
   that immediately follows each END-POINTS object.  In the future
   version, we may want to consider to define error values when the
   condition is not satisfied.

   So eventually the following cases are possible when modifying an
   existing P2MP LSP:

   Case 1: Adding leaves with full reoptimization of existing paths

           <PCReq Message>::= <Common Header>
                           <request>

                   where:

                   <request>::=<RP

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

            Figure 8: Adding Leaves with Full Reoptimization

   Case 2: Adding leaves with partial reoptimization of existing paths

           <PCReq Message>::= <Common Header>
                           <request>

                   where:

                   <request>::=<RP

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

            Figure 9: Adding Leaves with Partial Reoptimization

   Case 3: Adding leaves without reoptimization of existing paths

           <PCReq Message>::= <Common Header>
                           <request>

                    where:

                   <request>::=<RP

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

            Figure 10: Adding Leaves without Reoptimization

           <PCReq Message>::= <Common Header>
                           <request>

                   where:

                   <request>::=<RP
           Common Header
           RP with P2MP flag/R bits set>
                           <END-POINTS set
           END-POINTS for leaf type 2><RRO list>
                           <END-POINTS 2
             RRO list
           END-POINTS for leaf type 3><RRO list>
                           [OF] 3
             RRO list
           OF (optional)

            Figure 11: Pruning Leaves with Full Reoptimization

   Case 5: Pruning leaves with partial reoptimization of existing paths

           <PCReq Message>::= <Common Header>
                           <request>

                   where:

                   <request>::=<RP

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

            Figure 12: Pruning Leaves with Partial Reoptimization

   Case 6: Pruning leaves without reoptimization of existing paths

           <PCReq Message>::= <Common Header>
                           <request>

                   where:

                   <request>::=<RP

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

            Figure 13: Pruning Leaves without Reoptimization

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

           <PCReq Message>::= <Common Header>
                           <request>

                   where:

                   <request>::=<RP

           Common Header
           RP with P2MP flag/R bits set>
                           <END-POINTS set
           END-POINTS for leaf type 1>
                           <END-POINTS 1
           END-POINTS for leaf type 2><RRO list>
                           <END-POINTS 2
             RRO list
           END-POINTS for leaf type 3><RRO list>
                           [OF] 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

           <PCReq Message>::= <Common Header>
                           <request>

                   where:

                   <request>::=<RP

           Common Header
           RP with P2MP flag/R bits set>
                           <END-POINTS set
           END-POINTS for leaf type 1>
                           <END-POINTS 1
           END-POINTS for leaf type 2><RRO list>
                           <END-POINTS 2
             RRO list
           END-POINTS for leaf type 3><RRO list>
                           <END-POINTS 3
             RRO list
           END-POINTS for leaf type 4><RRO list>
                           [OF] 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
           <PCReq Message>::= <Common Header>
                           <request>

                   where:

                   <request>::=<RP

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

            Figure 16: Adding and Pruning Leaves without Reoptimization

3.11. 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 capability by using the mechanisms defined in
   [NODE-CAP].
   [PCE-P2MP-REQ].

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 backup of another
   P2MP LSP.  In this case, the path diversity for these two LSPs need
   to be considered during the path computation.

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

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

     <PCReq Message>::= <Common Header>
                   <SVEC

           Common Header
           SVEC for sync of LSP1 and LSP2>[OF]
                   <request-list>
         where:

           <request-list>::=<request1><request2>
                <request1>::= <RP with P2MP flag>
                                 <END-POINTS1 LSP2
           OF (optional)
           END-POINTS1 for P2MP>
                                 <RRO1 list>
                                 [<BANDWIDTH1>]

                <request2>::= <RP with P2MP flag>
                                 <END-POINTS2
            RRO1 list
           END-POINTS2 for P2MP>
                                 <RRO2 list>
                                 [<BANDWIDTH2>] P2MP
            RRO2 list

           Figure 17: PCReq Message Example for Synchronization

   We propose that two new flags are also added to the SVEC object for
   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.

3.13. Multi-Message Support

   The solution follows synchronization procedures defined in [RFC5440].

   If Request and Response Fragmentation

   In certain scenarios the P2MP request (i.e. <RP><END-POINTS>) is too large to may not fit into a single message it is permitted to divide it into multiple requests
   that would be carried in different messages.  That means that request or
   response message. For example, if a P2MP tree has many hundreds or
   thousands of leaves. Then the request would then contain or response may need to
   be fragmented into multiple requests with messages.

   The F bit has been outlined in section 3.3.1. The Extension of RP objects that
   have the same request IDs.

   Here is an example
   Object, of such P2MP request that this document. The F bit is divided used in 2 request
   messages:

     <PCReq Message1>::= <Common Header>
                   <SVEC, the Req-ID1 is repeated 2 times>
                   <request>

                where:

                   <request>::=< RP with Req-ID1 >
                                  <END-POINTs for P2MP>
                                  <RRO list>

     <PCReq Message2>::= <Common Header>
                   <request>

                where:

                  <request>::=< RP with Req-ID1>
                                 <END-POINTs for P2MP>
                                 <RRO list>

        Figure 18: PCReq Message Example for Message Fragmentation

   Note object header
   to signal that the SVEC object contains an intial request or response was too large to fit
   into a single message and should therfore be fragmented into
   multiple requests. In order to indentify the single request or
   response, each message will use the same request Id repeated N
   times where N ID.

3.13.1 Request Fragmentation Procedure

   If the intial request is too large to fit into a single request
   message the total number of RP objects included in all PCC will split the requst over multiple messages.  This is Each
   message sent to be able the PCE will have the F bit set in the RP object
   to detect signify that the whole P2MP request has been received.  Note that this assumes fragmented into multiple
   messages. In order to indentify that the transmission a series of
   the request messages
   represents a single request, each message will use the same
   request ID.

   The assumption is performed that request messages are reliably delivered
   and in consistent order, which is
   not a problem sequence since PCEP relies on TCP.

   To avoid

3.13.2 Response Fragmentation Procedure

   Once the backward compatible problem when a PCE that does not
   support P2MP extensions receives an SVEC with same computes a path based on the intial request Id twice,
   such message MUST NOT be sent to a non P2MP capable PCE.  Thanks
   response is sent back to the OPEN message discovery mechanism this PCC. If the response is possible too large to known.

   We propose to use fit
   into a single response message the SVEC/synctimer mechanism also for PCRep PCE will split the requst over
   multiple messages. Each message
   (in case sent to the PCE with the F bit set
   in the RP object to signify that the response has been fragmented
   into multiple messages. In order to indentify that a series of too large
   response message).  This was not defined in 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 base draft.  We propose relies on TCP.

3.13.3 Fragmentation Examples

  The following example illustrates the request message with Req-ID1,
  which adds one leaf to a 1200 leaves existing tree, is sent to the
  PCE. The assumption is that this feature should the one request message can hold up to
  800 leaves. In these conditions, the original one message needs to be defined
  sent over by two small messages, which have the Req-ID1 specified in The future version
  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 that the last fragmented message piece is lost, the
  receiver side of the PCEP draft. fragmented message may start a timer once it
  receives the first piece of the fragmented message. When timer expires
  and it still doesn't receive the last piece of the fragmented message,
  it should send an error message to the receiver to signal that it
  have recieved 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.

   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 2 3 4 5 6 7 0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IPv4 address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                           ...                                 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IPv4 address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 19: 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 2 3 4 5 6 7 0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |            Destination IPv6 address (16 bytes)                |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          ...                                  ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |              Destination IPv6 address (16 bytes)              |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 20: UNREACH_DESTINATION Object Body for IPv6

3.15. P2MP PCEP Error Object

   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:

   A new Error-Type (16) and subsequent error-values are defined as
   follows:

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

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

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

3.16. PCEP NO-PATH Indicator

   To communicate the reason(s) 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 2 3 4 5 6 7 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |C|        Flags                |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                      Optional TLV(s)                        //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 21:  The Format of the NO-PATH Object Body
   One new bit flags are is defined in the NO-PATH-VECTOR TLV carried in
   the NO-PATH Object:

   0x20: 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 list of destination(s) 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
   [PCEP],
   [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.

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.

   [PCEP] describes various mechanisms for denial of service attacks,
   and these tools MAY be advantageously used. Therefore it is
   more important that implementations conform to security requirements
   of [RFC5440], and the implementor utilize those security features

6. IANA Considerations

   A number of IANA considerations have been highlighted in the relevant previous
   sections of this document.  Further clarifications of these requests
   will be made in a future version of this document. In summary, IANA is requested to make
   allocations for the following PCEP parameters.

6.1 New Object Functions

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

   Objective Function Code: 8 (suggested value)
   Name: Minimum Cost Tree (MCT)

6.2 New Metric Object Types

   P2MP IGP metric: T=4 (suggested value)
   P2MP TE metric: T=5 (suggested value)
   P2MP hop count metric: T=6 (suggested value)

6.3 UNREACH_DESTINATION objects

   UNREACH_DESTINATION Object-Class

   UNREACH_DESTINATION Object-Type for IPv4

   UNREACH_DESTINATION Object-Type for IPv6

7. Acknowledgements

   The authors would like to thank Adrian Farrel, Young Lee, Dan
   Tappan,Autumn
   Tappan, Autumn Liu and 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.

   [PCE-P2MP-REQ]
              Yasukawa, S. and A.

   [RFC5511]  Farrel, "PCC-PCE Communication
              Requirements for Point F., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Multipoint Multiprotocol  Label
              Switching Traffic Engineering (MPLS-TE)",
              draft-ietf-pce-p2mp-req-01 (work Form Encoding Rules in progress),
              February 2008.

   [PCE-OF] 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)", draft-ietf-pce-of-06 (work in progress), 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-01.txt",
              draft-ietf-pce-p2mp-app-01 (work in progress),
              February 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 (work in progress),
              February 2008.

9. Authors' Addresses

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

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

   Fabien Verhaeghe
   Marben Products
   176 avenue Jean Jaures
   92800 Puteaux,
   France
   Email: fabien.verhaeghe@marben-products.com 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

   Mohamad Chaitou (editor)
   France

   Email: Mohamad. mohamad.chaitou@gmail.com
   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex,
   France
   Email: Jeanlouis.Leroux@orange-ftgroup.com
   Zafar Ali
   Cisco systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario  K2K 3E8
   Canada
   Email: zali@cisco.com

10. Intellectual Property Consideration

   The

   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 takes no position regarding and the validity or scope persons identified as authors
   of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or code.  All rights reserved.

   Redistribution and use of the technology
   described in any IETF Document source and binary forms, with or without
   modification, are permitted provided that the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result following conditions
   are met:

   o Redistributions of an attempt made to obtain a general license or
   permission for source code must retain the use of such proprietary rights by implementers or
   users of above copyright
     notice, this specification can be obtained from list of conditions and the IETF on-line IPR
   repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained following disclaimer.

   o Redistributions in an IETF Document. Please
   address the information to binary form must reproduce the IETF at ietf-ipr@ietf.org.

   The definitive version above copyright
     notice, this list of an IETF Document is that published by, or
   under conditions and the auspices of, following disclaimer in the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
     documentation and/or other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, materials provided with the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For
     distribution.

   o Neither the avoidance name of doubt, each Contributor to the Internet Society, IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to Trust, nor the
   provisions
     names of RFC 5378. No language specific contributors, may be used to the contrary, endorse or terms,
   conditions or rights that differ promote
     products derived from or are inconsistent with this software without specific prior written
     permission.

    Below is the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.

11. Disclaimer of Validity

   All IETF Documents and message format for the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

12. Full Copyright Statement

   Copyright (c) 2009 IETF Trust and 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 persons identified as bessage format for the
   document authors. All rights reserved.

   This document reply message:

       Below is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on message format for 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. 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>]