doc: Add RFC documents

1 files changed, 1851 insertions, 0 deletions

diff --git a/doc/rfc/rfc6006.txt b/doc/rfc/rfc6006.txt
new file mode 100644
index 0000000..04e438c
--- /dev/null
+++ b/doc/rfc/rfc6006.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      Q. Zhao, Ed.
+Request for Comments: 6006                             Huawei Technology
+Category: Standards Track                                   D. King, Ed.
+ISSN: 2070-1721                                       Old Dog Consulting
+                                                            F. Verhaeghe
+                                             Thales Communication France
+                                                               T. Takeda
+                                                         NTT Corporation
+                                                                  Z. Ali
+                                                     Cisco Systems, Inc.
+                                                               J. Meuric
+                                                          France Telecom
+                                                          September 2010
+
+
+                             Extensions to
+       the Path Computation Element Communication Protocol (PCEP)
+    for Point-to-Multipoint Traffic Engineering Label Switched Paths
+
+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 point-to-multipoint (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 is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6006.
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                    [Page 1]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................4
+      1.2. Requirements Language ......................................5
+   2. PCC-PCE Communication 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 ..............................7
+      3.2. Efficient Presentation of P2MP 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 ....................................12
+      3.5. Reply Message Format ......................................12
+      3.6. P2MP Objective Functions and Metric Types .................13
+           3.6.1. New Objective Functions ............................13
+           3.6.2. New Metric Object Types ............................14
+      3.7. Non-Support of P2MP Path Computation ......................14
+
+
+
+Zhao, et al.                 Standards Track                    [Page 2]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+      3.8. Non-Support by Back-Level PCE Implementations .............15
+      3.9. P2MP TE Path Reoptimization Request .......................15
+      3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........16
+      3.11. Discovering Branch Nodes .................................19
+           3.11.1. Branch Node Object ................................19
+      3.12. Synchronization of P2MP TE Path Computation Requests .....19
+      3.13. Request and Response Fragmentation .......................20
+           3.13.1. Request Fragmentation Procedure ...................21
+           3.13.2. Response Fragmentation Procedure ..................21
+           3.13.3. Fragmentation Examples ............................21
+      3.14. UNREACH-DESTINATION Object ...............................22
+      3.15. P2MP PCEP-ERROR Objects and Types ........................23
+      3.16. PCEP NO-PATH Indicator ...................................24
+   4. Manageability Considerations ...................................25
+      4.1. Control of Function and Policy ............................25
+      4.2. Information and Data Models ...............................25
+      4.3. Liveness Detection and Monitoring .........................25
+      4.4. Verifying Correct Operation ...............................25
+      4.5. Requirements for Other Protocols and Functional
+           Components ................................................26
+      4.6. Impact on Network Operation ...............................26
+   5. Security Considerations ........................................26
+   6. IANA Considerations ............................................27
+      6.1. PCEP TLV Type Indicators ..................................27
+      6.2. Request Parameter Bit Flags ...............................27
+      6.3. Objective Functions .......................................27
+      6.4. Metric Object Types .......................................27
+      6.5. PCEP Objects ..............................................28
+      6.6. PCEP-ERROR Objects and Types ..............................29
+      6.7. PCEP NO-PATH Indicator ....................................30
+      6.8. SVEC Object Flag ..........................................30
+      6.9. OSPF PCE Capability Flag ..................................30
+   7. Acknowledgements ...............................................30
+   8. References .....................................................30
+      8.1. Normative References ......................................30
+      8.2. Informative References ....................................32
+
+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.
+
+
+
+Zhao, et al.                 Standards Track                    [Page 3]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   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 Label
+   Switching Routers (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 Engineering 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.
+
+   This document also uses the terminology defined in [RFC4655],
+   [RFC4875], and [RFC5440].
+
+
+
+
+Zhao, et al.                 Standards Track                    [Page 4]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+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.  PCC-PCE Communication Requirements
+
+   This section summarizes the PCC-PCE communication requirements for
+   P2MP MPLS-TE LSPs described in [RFC5862].  The numbering system
+   corresponds to the requirement numbers used in [RFC5862].
+
+   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.  By default, the path returned by the PCE SHOULD use the
+       compressed format.
+
+   8.  It MUST be possible for a single P2MP path computation request or
+       response to be conveyed by a sequence of messages.
+
+   9.  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.
+
+   10. P2MP path modification and P2MP path diversity MUST be supported.
+
+   11. It MUST be possible to reoptimize existing P2MP TE LSPs.
+
+   12. It MUST be possible to add and remove P2MP destinations from
+       existing paths.
+
+
+
+
+Zhao, et al.                 Standards Track                    [Page 5]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   13. It MUST be possible to specify a list of applicable branch nodes
+       to use when computing the P2MP path.
+
+   14. It MUST be possible for a PCC to discover P2MP path computation
+       capability.
+
+   15. 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 ("PCC-PCE
+   Communication 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 Link State Advertisement (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 assignment 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 (10) 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.3.2 ("The New P2MP END-POINTS
+   Object") to further qualify the level of support.
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                    [Page 6]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+3.1.2.  Open Message Extension
+
+   Based on the Capabilities Exchange requirement described in
+   [RFC5862], 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.
+
+   IANA has allocated value 6 from the "PCEP TLV Type Indicators" sub-
+   registry, as documented in Section 6.1 ("PCEP TLV Type Indicators").
+   The description is "P2MP capable", and 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 [RFC5862], it may be necessary to pass existing
+   P2MP LSP route information between the PCC and PCE in the request and
+   reply messages.  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 Resource Reservation Protocol Traffic
+   Engineering (RSVP-TE) extensions 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].
+
+
+
+
+Zhao, et al.                 Standards Track                    [Page 7]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   The Secondary Record 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    29
+   Name                  SERO
+   Object-Type           1: SERO
+                         2-15: Unassigned
+   Reference             RFC 6006
+
+   Object-Class Value    30
+   Name                  SRRO
+   Object-Type           1: SRRO
+                         2-15: Unassigned
+   Reference             RFC 6006
+
+   The IANA assignment is documented 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-POINTS 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 messages will need the
+   following additional parameters to indicate to the receiving PCE that
+   the request and reply messages have been fragmented across multiple
+   messages, that they have been requested for a P2MP path, and whether
+   the route is represented in the compressed or uncompressed format.
+
+   This document adds the following flags to the RP Object:
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                    [Page 8]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   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 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 is
+   not for P2MP.
+
+   o  N (P2MP bit - 1 bit):
+
+      0: This indicates that this is not a PCReq or PCRep message for
+         P2MP.
+
+      1: This indicates that this is a 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 is not in the compressed format.  By default, the path
+   returned by the PCE SHOULD 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 assignment is documented 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-POINTS
+   objects for the P2MP path:
+
+
+
+
+
+Zhao, et al.                 Standards Track                    [Page 9]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   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 that 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.
+
+   Note that a P2MP path computation request can mix the different types
+   of leaves by including several END-POINTS objects per RP object as
+   shown in the PCReq Routing Backus-Naur Form (RBNF) [RFC5511] format
+   in Section 3.4 ("Request Message Format").
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 10]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   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
+
+   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.
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 11]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+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 that 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 assignment of 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].
+
+
+
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 12]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   Below is the message format for the reply message:
+
+          <PCRep Message>::= <Common Header>
+                                <response>
+          <response>::=<RP>
+                          [<end-point-path-pair-list>]
+                          [<NO-PATH>]
+                          [<attribute-list>]
+
+        where:
+
+           <end-point-path-pair-list>::=
+                   [<END-POINTS>]<path>[<end-point-path-pair-list>]
+
+          <path> ::= (<ERO>|<SERO>) [<path>]
+
+          <attribute-list>::=[<OF>]
+                               [<LSPA>]
+                               [<BANDWIDTH>]
+                               [<metric-list>]
+                               [<IRO>]
+
+            Figure 4.  The Message Format for the Reply Message
+
+   The optional END-POINTS object 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 that 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.
+
+
+
+Zhao, et al.                 Standards Track                   [Page 13]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   Objective Function Code: 7
+
+      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
+
+      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
+
+   o  P2MP TE metric: T=9
+
+   o  P2MP hop count metric: T=10
+
+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).
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 14]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+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.
+
+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-bit 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 distinct leaves whose path cannot be
+   modified.  An example of the PCReq message in this scenario would be:
+
+           Common Header
+           RP with P2MP flag/R-bit 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
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 15]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+3.10.  Adding and Pruning Leaves to/from the P2MP Tree
+
+   When adding new leaves to or removing old leaves from 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 for adding new leaves to or removing old leaves from the
+   existing P2MP tree.
+
+   To add new leaves, the user MUST build a P2MP request using END-
+   POINTS with leaf type 1.
+
+   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 of
+   satisfying the request due to no END-POINTS with leaf type 2.
+
+   When adding new leaves to or removing old leaves from the existing
+   P2MP tree, the PCC must also provide the list of old leaves, if any,
+   including END-POINTS with leaf type 3, leaf type 4, or both.  New
+   PCEP-ERROR objects and types are necessary for reporting when certain
+   conditions are not satisfied (i.e., when there are no END-POINTS with
+   leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1
+   or 2).  A generic "Inconsistent END-POINT" error will be used if a
+   PCC receives a request that has an inconsistent END-POINT (i.e., if a
+   leaf specified as type 1 already exists).  These IANA assignments are
+   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-bit set
+           END-POINTS for leaf type 1
+             RRO list
+           END-POINTS for leaf type 3
+             RRO list
+           OF (optional)
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 16]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   Case 2: Adding leaves with partial reoptimization of existing paths
+
+           Common Header
+           RP with P2MP flag/R-bit 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
+
+           Common Header
+           RP with P2MP flag/R-bit 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 of existing paths
+
+           Common Header
+           RP with P2MP flag/R-bit 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-bit 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)
+
+
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 17]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   Case 6: Pruning leaves without reoptimization of existing paths
+
+           Common Header
+           RP with P2MP flag/R-bit 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 with full reoptimization of
+   existing paths
+
+           Common Header
+           RP with P2MP flag/R-bit 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-bit 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-bit 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)
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 18]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+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
+   Branch Node Capability (BNC) Object.  The BNC Object has the same
+   format as the Include Route Object (IRO) defined in [RFC5440], except
+   that it only supports IPv4 and IPv6 prefix sub-objects.  Two Object-
+   types are also defined:
+
+   o  Branch node list: List of nodes that can be used as branch nodes.
+
+   o  Non-branch node list: List of nodes that cannot be used as branch
+      nodes.
+
+   The object can only be carried in a PCReq message.  A Path Request
+   may carry at most one Branch Node Object.
+
+   The Object-Class and Object-types have been allocated by IANA.  The
+   IANA assignment 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 diversity for these dependent
+   LSPs may need to be considered during the path computation.
+
+   The synchronization can be done by using the existing Synchronization
+   VECtor (SVEC) functionality defined in [RFC5440].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 19]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   An example of synchronizing two P2MP LSPs, each having two leaves for
+   Path Computation Request Messages, is illustrated 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 diversity for specific
+   leaves or a specific S2L sub-path to the primary P2MP path tree.  The
+   second flag, would allow the PCC to request that partial paths should
+   be link direction diverse.
+
+   The 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 diversity for a
+      specific leaf, a set of leaves, or all leaves.
+
+   o  D (Link Direction Diverse bit - 1 bit):
+
+      When set, this would indicate a request that a partial path or
+      paths should be link direction diverse.
+
+   The IANA assignment 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.
+
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 20]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   The F-bit has been outlined in "The Extension of the RP Object"
+   (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
+
+   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.
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 21]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+           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 a scenario where 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
+   documented 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 28.
+   UNREACH-DESTINATION Object-Type for IPv4 is 1.
+   UNREACH-DESTINATION Object-Type for IPv6 is 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 22]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 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]:
+
+
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 23]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   Error-Type=5; Error-Value=7: if a PCE receives a P2MP path
+   computation request that 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.
+
+   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; Error-Value=1: if a PCE receives a P2MP path request
+   and the PCE is not capable of satisfying 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 also be 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.14.
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 24]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+4.  Manageability Considerations
+
+   [RFC5862] describes various manageability requirements in support of
+   P2MP path computation when applying PCEP.  This section describes how
+   manageability requirements mentioned in [RFC5862] are supported in
+   the context of PCEP extensions specified in this document.
+
+   Note that [RFC5440] describes various manageability considerations in
+   PCEP, and most of the manageability requirements mentioned in
+   [RFC5862] 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 or disable P2MP path computations on the
+      PCE.
+
+   o  The PCE may be configured to enable or disable the advertisement
+      of its P2MP path computation capability.  A PCE can advertise 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].  [RFC5862]
+   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 [RFC5862] 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.
+
+
+
+Zhao, et al.                 Standards Track                   [Page 25]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+4.5.  Requirements for 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.
+
+   The subsequent IANA assignments are documented in Section 6.9 ("OSPF
+   PCE Capability Flag") of this document.
+
+4.6.  Impact on Network Operation
+
+   It is expected that the 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 [RFC5862], 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 a 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 of [RFC5440]).
+
+   o  Authenticating the PCEP requests and responses to ensure the
+      message is intact and sent from an authorized node (Section 10.3
+      of [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 of [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.
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 26]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   PCEP implementations SHOULD consider the additional security provided
+   by the TCP Authentication Option (TCP-AO) [RFC5925].
+
+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 has made the following allocations.
+
+6.1.  PCEP TLV Type Indicators
+
+   As described in Section 3.1.2., the newly defined P2MP capability TLV
+   allows the PCE to advertise its P2MP path computation capability.
+   IANA has made the following allocation from the "PCEP TLV Type
+   Indicators" sub-registry.
+
+      Value       Description          Reference
+      6           P2MP capable         RFC 6006
+
+6.2.  Request Parameter Bit Flags
+
+   As described in Section 3.3.1, three new RP Object Flags have been
+   defined.  IANA has made the following allocations from the PCEP "RP
+   Object Flag Field" sub-registry:
+
+      Bit      Description                         Reference
+
+      18       Fragmentation (F-bit)               RFC 6006
+      19       P2MP (N-bit)                        RFC 6006
+      20       ERO-compression (E-bit)             RFC 6006
+
+6.3.  Objective Functions
+
+   As described in Section 3.6.1, two new Objective Functions have been
+   defined.  IANA has made the following allocations from the PCEP
+   "Objective Function" sub-registry:
+
+      Code Point        Name        Reference
+
+      7                 SPT         RFC 6006
+      8                 MCT         RFC 6006
+
+6.4.  Metric Object Types
+
+   As described in Section 3.6.2, three new metric object T fields have
+   been defined.  IANA has made the following allocations from the PCEP
+   "METRIC Object T Field" sub-registry:
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 27]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+      Value           Description               Reference
+
+      8               P2MP IGP metric           RFC 6006
+      9               P2MP TE metric            RFC 6006
+      10              P2MP hop count metric     RFC 6006
+
+6.5.  PCEP Objects
+
+   As discussed in Section 3.3.2, two new END-POINTS Object-Types are
+   defined.  IANA has made the following Object-Type allocations from
+   the "PCEP Objects" sub-registry:
+
+      Object-Class Value    4
+      Name                  END-POINTS
+      Object-Type           3: IPv4
+                            4: IPv6
+                            5-15: Unassigned
+      Reference             RFC 6006
+
+   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 has made 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             RFC 6006
+
+      Object-Class Value    29
+      Name                  SERO
+      Object-Type           1: SERO
+                            2-15: Unassigned
+      Reference             RFC 6006
+
+      Object-Class Value    30
+      Name                  SRRO
+      Object-Type           1: SRRO
+                            2-15: Unassigned
+      Reference             RFC 6006
+
+
+
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 28]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+      Object-Class Value    31
+      Name                  Branch Node Capability Object
+      Object-Type           1: Branch node list
+                            2: Non-branch node list
+                            3-15: Unassigned
+      Reference             RFC 6006
+
+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 has made the following
+   allocations from the PCEP "PCEP-ERROR Object Error Types and Values"
+   sub-registry:
+
+      Error
+      Type  Meaning                                            Reference
+
+      5     Policy violation
+              Error-value=7:                                   RFC 6006
+                P2MP Path computation is not allowed
+
+      16    P2MP Capability Error
+              Error-Value=0: Unassigned                        RFC 6006
+              Error-Value=1:                                   RFC 6006
+                The PCE is not capable to satisfy the request
+                due to insufficient memory
+              Error-Value=2:                                   RFC 6006
+                The PCE is not capable of P2MP computation
+
+      17    P2MP END-POINTS Error
+              Error-Value=0: Unassigned                        RFC 6006
+              Error-Value=1:                                   RFC 6006
+                The PCE is not capable to satisfy the request
+                due to no END-POINTS with leaf type 2
+              Error-Value=2:                                   RFC 6006
+                The PCE is not capable to satisfy the request
+                due to no END-POINTS with leaf type 3
+              Error-Value=3:                                   RFC 6006
+                The PCE is not capable to satisfy the request
+                due to no END-POINTS with leaf type 4
+              Error-Value=4:                                   RFC 6006
+                The PCE is not capable to satisfy the request
+                due to inconsistent END-POINTS
+
+      18    P2MP Fragmentation Error
+              Error-Value=0: Unassigned                        RFC 6006
+              Error-Value=1:                                   RFC 6006
+                Fragmented request failure
+
+
+
+Zhao, et al.                 Standards Track                   [Page 29]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+6.7.  PCEP NO-PATH Indicator
+
+   As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field has
+   been defined.  IANA has made the following allocation from the PCEP
+   "NO-PATH-VECTOR TLV Flag Field" sub-registry:
+
+      Bit    Description                               Reference
+
+      24     P2MP Reachability Problem                 RFC 6006
+
+6.8.  SVEC Object Flag
+
+   As discussed in Section 3.12, two new SVEC Object Flags are defined.
+   IANA has made the following allocation from the PCEP "SVEC Object
+   Flag Field" sub-registry:
+
+      Bit      Description                              Reference
+
+      19       Partial Path Diverse                     RFC 6006
+      20       Link Direction Diverse                   RFC 6006
+
+6.9.  OSPF PCE Capability Flag
+
+   As discussed in Section 3.1.1, a new OSPF Capability Flag is defined
+   to indicate P2MP path computation capability.  IANA has made the
+   following assignment from the OSPF Parameters "Path Computation
+   Element (PCE) Capability Flags" registry:
+
+      Bit      Description                              Reference
+
+      10       P2MP path computation                    RFC 6006
+
+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 document.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 30]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+   [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., Ed., "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.
+
+   [RFC4875]   Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
+               Yasukawa, Ed., "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., Ed., Shen, N., Vasseur, JP., Aggarwal, R.,
+               and S. Shaffer, "Extensions to OSPF for Advertising
+               Optional Router Capabilities", RFC 4970, July 2007.
+
+   [RFC5073]   Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing
+               Protocol Extensions for Discovery of Traffic Engineering
+               Node Capabilities", RFC 5073, December 2007.
+
+   [RFC5088]   Le Roux, JL., Ed., Vasseur, JP., Ed., 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, A., "Routing Backus-Naur Form (RBNF): A Syntax
+               Used to Form Encoding Rules in Various Routing Protocol
+               Specifications", RFC 5511, April 2009.
+
+   [RFC5440]   Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
+               Computation Element (PCE) Communication Protocol (PCEP)",
+               RFC 5440, March 2009.
+
+   [RFC5541]   Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
+               Objective Functions in the Path Computation Element
+               Communication Protocol (PCEP)", RFC 5541, June 2009.
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 31]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+8.2.  Informative References
+
+   [RFC4655]   Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+               Computation Element (PCE)-Based Architecture", RFC 4655,
+               August 2006.
+
+   [RFC4657]   Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
+               Element (PCE) Communication Protocol Generic
+               Requirements", RFC 4657, September 2006.
+
+   [RFC5671]   Yasukawa, S. and A. Farrel, Ed., "Applicability of the
+               Path Computation Element (PCE) to Point-to-Multipoint
+               (P2MP) MPLS and GMPLS Traffic Engineering (TE)",
+               RFC 5671, October 2009.
+
+   [RFC5862]   Yasukawa, S. and A. Farrel, "Path Computation Clients
+               (PCC) - Path Computation Element (PCE) Requirements for
+               Point-to-Multipoint MPLS-TE", RFC 5862, June 2010.
+
+   [RFC5925]   Touch, J., Mankin, A., and R. Bonica, "The TCP
+               Authentication Option", RFC 5925, June 2010.
+
+   [PCEP-MIB]  Koushik, K., Stephan, E., Zhao, Q., and D. King, "PCE
+               communication protocol (PCEP) Management Information
+               Base", Work in Progress, July 2010.
+
+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, et al.                 Standards Track                   [Page 32]
+
+RFC 6006           Extensions to PCEP for P2MP TE LSPs    September 2010
+
+
+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
+   France
+   EMail: julien.meuric@orange-ftgroup.com
+
+
+
+
+
+
+Zhao, et al.                 Standards Track                   [Page 33]
+