doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc5671.txt b/doc/rfc/rfc5671.txt
new file mode 100644
index 0000000..ca9391c
--- /dev/null
+++ b/doc/rfc/rfc5671.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                        S. Yasukawa
+Request for Comments: 5671                                           NTT
+Category: Informational                                   A. Farrel, Ed.
+                                                      Old Dog Consulting
+                                                            October 2009
+
+
+         Applicability of the Path Computation Element (PCE) to
+   Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)
+
+Abstract
+
+   The Path Computation Element (PCE) provides path computation
+   functions in support of traffic engineering in Multiprotocol Label
+   Switching (MPLS) and Generalized MPLS (GMPLS) networks.
+
+   Extensions to the MPLS and GMPLS signaling and routing protocols have
+   been made in support of point-to-multipoint (P2MP) Traffic Engineered
+   (TE) Label Switched Paths (LSPs).
+
+   This document examines the applicability of PCE to path computation
+   for P2MP TE LSPs in MPLS and GMPLS networks.  It describes the
+   motivation for using a PCE to compute these paths and examines which
+   of the PCE architectural models are appropriate.
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+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
+   (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 BSD License.
+
+
+
+
+
+
+Yasukawa & Farrel            Informational                      [Page 1]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Architectural Considerations ....................................4
+      2.1. Offline Computation ........................................4
+      2.2. Online Computation .........................................4
+           2.2.1. LSR Loading .........................................5
+           2.2.2. PCE Overload ........................................6
+           2.2.3. PCE Capabilities ....................................6
+   3. Fragmenting the P2MP Tree .......................................7
+   4. Central Replication Points ......................................8
+   5. Reoptimization and Modification .................................9
+   6. Repair .........................................................10
+   7. Disjoint Paths .................................................11
+   8. Manageability Considerations ...................................11
+      8.1. Control of Function and Policy ............................11
+      8.2. Information and Data Models ...............................11
+      8.3. Liveness Detection and Monitoring .........................12
+      8.4. Verifying Correct Operation ...............................12
+      8.5. Requirements on Other Protocols and Functional
+           Components ................................................12
+      8.6. Impact on Network Operation ...............................13
+   9. Security Considerations ........................................13
+   10. Acknowledgments ...............................................13
+   11. References ....................................................13
+      11.1. Normative References .....................................13
+      11.2. Informative References ...................................13
+
+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 of applying computational constraints.  The
+   intention is that the PCE is used to compute the path of Traffic
+   Engineered Label Switched Paths (TE LSPs) within Multiprotocol Label
+   Switching (MPLS) and Generalized MPLS (GMPLS) networks.
+
+   [RFC4655] defines various deployment models that place PCEs
+   differently within the network.  The PCEs may be collocated with the
+   Label Switching Routers (LSRs), may be part of the management system
+   that requests the LSPs to be established, or may be positioned as one
+   or more computation servers within the network.
+
+   Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are
+   documented in [RFC4461], and signaling protocol extensions for
+   setting up P2MP MPLS TE LSPs are defined in [RFC4875].  In this
+
+
+
+
+
+Yasukawa & Farrel            Informational                      [Page 2]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+   document, P2MP MPLS TE networks are considered in support of various
+   features including layer 3 multicast VPNs [RFC4834], video
+   distribution, etc.
+
+   Fundamental to the determination of the paths for P2MP LSPs within a
+   network is the selection of branch points.  Not only is this
+   selection constrained by the network topology and available network
+   resources, but it is determined by the objective functions that may
+   be applied to path computation.  For example, one standard objective
+   is to minimize the total cost of the tree (that is, to minimize the
+   sum of the costs of each link traversed by the tree) to produce what
+   is known as a Steiner tree.  Another common objective function
+   requires that the cost to reach each leaf of the P2MP tree be
+   minimized.
+
+   The selection of branch points within the network is further
+   complicated by the fact that not all LSRs in the network are
+   necessarily capable of performing branching functions.  This
+   information may be recorded in the Traffic Engineering Database (TED)
+   that the PCE uses to perform its computations, and may have been
+   distributed using extensions to the Interior Gateway Protocol (IGP)
+   operating within the network [RFC5073].
+
+   Additionally, network policies may dictate specific branching
+   behavior.  For example, it may be decided that, for certain types of
+   LSPs in certain types of networks, it is important that no branch LSR
+   is responsible for handling more than a certain number of downstream
+   branches for any one LSP.  This might arise because the replication
+   mechanism used at the LSRs is a round-robin copying process that
+   delays the data transmission on each downstream branch by the time
+   taken to replicate the data onto each previous downstream branch.
+   Alternatively, administrative policies may dictate that replication
+   should be concentrated on specific key replication nodes behaving
+   like IP multicast rendezvous points (perhaps to ensure appropriate
+   policing of receivers in the P2MP tree, or perhaps to make protection
+   and resiliency easier to implement).
+
+   Path computation for P2MP TE LSPs presents a significant challenge
+   because of the complexity of the computations described above.
+   Determining disjoint protection paths for P2MP TE LSPs can add
+   considerably to this complexity, while small modifications to a P2MP
+   tree (such as adding or removing just one leaf) can completely change
+   the optimal path.  Reoptimization of a network containing multiple
+   P2MP TE LSPs requires considerable computational resources.  All of
+   this means that an ingress LSR might not have sufficient processing
+   power to perform the necessary computations, and even if it does, the
+   act of path computation might interfere with the control and
+
+
+
+
+Yasukawa & Farrel            Informational                      [Page 3]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+   management plane operation necessary to maintain existing LSPs.  The
+   PCE architecture offers a way to offload such path computations from
+   LSRs.
+
+2.  Architectural Considerations
+
+2.1.  Offline Computation
+
+   Offline path computation is performed ahead of time, before the LSP
+   setup is requested.  That means that it is requested by, or performed
+   as part of, a management application.  This model can be seen in
+   Section 5.5 of [RFC4655].
+
+   The offline model is particularly appropriate to long-lived LSPs
+   (such as those present in a transport network) or for planned
+   responses to network failures.  In these scenarios, more planning is
+   normally a feature of LSP provisioning.
+
+   This model may also be used where the network operator wishes to
+   retain full manual control of the placement of LSPs, using the PCE
+   only as a computation tool to assist the operator, not as part of an
+   automated network.
+
+   Offline path computation may be applied as a background activity for
+   network reoptimization to determine whether and when the current LSP
+   placements are significantly sub-optimal.  See Section 5 for further
+   discussions of reoptimization.
+
+2.2.  Online Computation
+
+   Online path computation is performed on-demand as LSRs in the network
+   determine that they need to know the paths to use for LSPs.  Thus,
+   each computation is triggered by a request from an LSR.
+
+   As described in [RFC4655], the path computation function for online
+   computation may be collocated with the LSR that makes the request, or
+   it may be present in a computation-capable PCE server within the
+   network.  The PCE server may be another LSR in the network, a
+   dedicated server, or a functional component of a Network Management
+   System (NMS).  Furthermore, the computation is not necessarily
+   achieved by a single PCE operating on its own, but may be the result
+   of cooperation between several PCEs.
+
+   The remainder of this document makes frequent reference to these
+   different online models in order to indicate which is more
+   appropriate in different P2MP scenarios.
+
+
+
+
+
+Yasukawa & Farrel            Informational                      [Page 4]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+2.2.1.  LSR Loading
+
+   An important feature of P2MP path computation is the processing load
+   that it places on the network element that is determining the path.
+   Roughly speaking, the load to compute a least-cost-to-leaf tree is
+   the same as the cost to compute a single optimal path to each leaf in
+   turn.  The load to compute a Steiner tree is approximately an order
+   of magnitude greater, although algorithms exist to approximate
+   Steiner trees in roughly the same order of magnitude of time as for a
+   least-cost-to-leaf tree.
+
+   Whereas many LSRs are capable of simple Constrained Shortest Path
+   First (CSPF) computations to determine a path for a single point-to-
+   point (P2P) LSP, they rapidly become swamped if called on to perform
+   multiple such computations, such as when recovering from a network
+   failure.  Thus, it is reasonable to expect that an LSR would struggle
+   to handle a P2MP path computation for a tree with many destinations.
+
+   The result of an LSR becoming overloaded by a P2MP path computation
+   may be two-fold.  First, the LSR may be unable to provide timely
+   computations of paths for P2P LSPs; this may impact LSP setup times
+   for simple demand-based services and could damage the LSR's ability
+   to recover services after network faults.  Secondly, the LSR's
+   processing capabilities may be diverted from other important tasks,
+   not the least of which is maintaining the control plane protocols
+   that are necessary to the support of existing LSPs and forwarding
+   state within the network.  It is obviously critically important that
+   existing traffic should not be disrupted by the computation of a path
+   for a new LSP.
+
+   It is also not reasonable to expect the ingress LSRs of P2MP LSRs to
+   be specially powerful and capable of P2MP computations.  Although a
+   solution to the overloading problem would be to require that all LSRs
+   that form the ingresses to P2MP LSPs be sufficiently high-capacity to
+   perform P2MP computations, this is not an acceptable solution
+   because, in all other senses, the ingress to a P2MP LSP is just a
+   normal ingress LSR.
+
+   Thus, there is an obvious solution: off-load P2MP path computations
+   from LSRs to remotely located PCEs.  Such PCE function can be
+   provided on dedicated or high-capacity network elements (such as
+   dedicated servers, or high-end routers that might be located as
+   Autonomous System Border Routers - ASBRs).
+
+
+
+
+
+
+
+
+Yasukawa & Farrel            Informational                      [Page 5]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+2.2.2.  PCE Overload
+
+   Since P2MP path computations are resource-intensive, it may be that
+   the introduction of P2MP LSPs into an established PCE network will
+   cause overload at the PCEs.  That is, the P2MP computations may block
+   other P2P computations and might even overload the PCE.
+
+   Several measures can be taken within the PCE architecture to
+   alleviate this situation as described in [RFC4655].  For example,
+   path computation requests can be assigned priorities by the LSRs that
+   issue them.  Thus, the LSRs could assign lower priority to the P2MP
+   requests, ensuring that P2P requests were serviced in preference.
+   Furthermore, the PCEs are able to apply local and network-wide policy
+   and this may dictate specific processing rules [RFC5394].
+
+   But ultimately, a network must possess sufficient path computation
+   resources for its needs and this is achieved within the PCE
+   architecture simply by increasing the number of PCEs.
+
+   Once there are sufficient PCEs available within the network, the LSRs
+   may choose between them and may use overload notification information
+   supplied by the PCEs to spot which PCEs are currently over-loaded.
+   Additionally, a PCE that is becoming over-loaded may redistribute its
+   queue of computation requests (using the PCE cooperation model
+   described in [RFC4655]) to other, less burdened PCEs within the
+   network.
+
+2.2.3.  PCE Capabilities
+
+   An LSR chooses between available PCEs to select the one most likely
+   to be able to perform the requested path computation.  This selection
+   may be based on overload notifications from the PCEs, but could also
+   consider other computational capabilities.
+
+   For example, it is quite likely that only a subset of the PCEs in the
+   network have the ability to perform P2MP computations since this
+   requires advanced functionality.  Some of those PCEs might have the
+   ability to satisfy certain objective functions (for example, least
+   cost to destination), but lack support for other objective functions
+   (for example, Steiner).  Additionally, some PCEs might not be capable
+   of the more complex P2MP reoptimization functionality.
+
+   The PCE architecture allows an LSR to discover the capabilities of
+   the PCEs within the network at the same time it discovers their
+   existence.  Further and more detailed exchanges of PCE capabilities
+   can be made directly between the PCEs and the LSRs.  This exchange of
+   PCE capabilities information allows a Path Computation Client (PCC)
+   to select the PCE that can best answer its computation requests.
+
+
+
+Yasukawa & Farrel            Informational                      [Page 6]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+3.  Fragmenting the P2MP Tree
+
+   A way to reduce the computational burden of computing a large P2MP
+   tree on a single PCE is to fragment or partition the tree.  This may
+   be particularly obvious in a multi-domain network (such as multiple
+   routing areas), but is equally applicable in a single domain.
+
+   Consider the network topology in Figure 1.  A P2MP LSP is required
+   from ingress LSR A to egress LSRs s, t, u, v, w, x, y, and z.  Using
+   a single PCE model, LSR A may request the entire path of the tree and
+   this may be supplied by the PCE.  Alternatively, the PCE that is
+   consulted by LSR A may only compute the first fragment of the tree
+   (for example, from A to K, L, and M) and may rely on other PCEs to
+   compute the three smaller trees from K to t, u, and v; from L to w
+   and x; and from M to s, y, and z.
+
+   The LSR consulted by A may simply return the first subtree and leave
+   LSRs K, L, and M to invoke PCEs in their turn in order to complete
+   the signaling.  Alternatively, the first PCE may cooperate with other
+   PCEs to collect the paths for the later subtrees and return them in a
+   single computation response to PCE A.  The mechanisms for both of
+   these approaches are described in the PCE architecture [RFC4655].
+
+                                       t
+                                      /
+                                     /
+                                    n--u
+                                   /
+                                  /
+                        e--f--h--K--o--v
+                       /
+                      /
+               A--b--c--d--g--i--L--p--w
+                            \        \
+                             \        \
+                              j        x
+                               \
+                                \
+                                 M--r--y
+                                  \  \
+                                   \  \
+                                    s  z
+
+        Figure 1: A P2MP Tree with Intermediate Computation Points
+
+
+
+
+
+
+
+Yasukawa & Farrel            Informational                      [Page 7]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+   A further possibility is that LSRs at which the subtrees are stitched
+   together (K, L, and M in this example) are selected from a set of
+   potential such points using a cooperative PCE technique, such as the
+   Backward Recursive Path Computation (BRPC) mechanism [RFC5441].
+   Indeed, if LSRs K, L, and M were ASBRs or Area Border Routers (ABRs),
+   the BRPC technique would be particularly applicable.
+
+   Note, however, that while these mechanisms are superficially
+   beneficial, it is far from obvious how the first LSR selects the
+   transit LSRs K, L, and M, or how the leaf nodes are assigned to be
+   downstream of particular downstream nodes.  The computation to
+   determine these questions may be no less intensive than the
+   determination of the full tree unless there is some known property of
+   the leaf node identifiers such as might be provided by address
+   aggregation.
+
+4.  Central Replication Points
+
+   A deployment model for P2MP LSPs is to use centralized, well-known
+   replication points.  This choice may be made for administrative or
+   security reasons, or because of particular hardware capability
+   limitations within the network.  Indeed, this deployment model can be
+   achieved using P2P LSPs between ingress and replication point as well
+   as between replication point and each leaf so as to achieve a P2MP
+   service without the use of P2MP MPLS-TE.
+
+   The motivations for this type of deployment are beyond the scope of
+   this document, but it is appropriate to examine how PCE might be used
+   to support this model.
+
+   In Figure 2, a P2MP service is required from ingress LSR a to egress
+   LSRs m, n, o, and p.  There are four replication-capable LSRs in the
+   network: D, E, J, and K.
+
+   When LSR a consults a PCE, it could be given the full P2MP path from
+   LSR a to the leaves, but in this model, the PCE simply returns a P2P
+   path to the first replication point (in this case, LSR D).  LSR D
+   will consult a PCE in its turn and determine the P2P LSPs to egress
+   LSRs m and p as well as the P2P LSP to the next replication point,
+   LSR J.  Finally, LSR J will use a PCE to determine P2P LSPs to
+   egresses n and o.
+
+
+
+
+
+
+
+
+
+
+Yasukawa & Farrel            Informational                      [Page 8]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+                                f--i--m
+                               /
+                              /
+                    a--b--c--D--g--J--n
+                              \     \
+                               \     \
+                             E  h  K  o
+                                 \
+                                  \
+                                   l--p
+
+              Figure 2: Using Centralized Replication Points
+
+   In this model of operation, it is quite likely that the PCE function
+   is located at the replication points, which will be high-capacity
+   LSRs.  One of the main features of the computation activity is the
+   selection of the replication points (for example, why is LSR D
+   selected in preference to LSR E, and why is LSR J chosen over LSR
+   K?).  This selection may be made solely on the basis of path
+   optimization as it would be for a P2MP computation, but may also be
+   influenced by policy issues (for example, LSR D may be able to give
+   better security to protect against rogue leaf attachment) or network
+   loading concerns (for example, LSR E may already be handling a very
+   large amount of traffic replication for other P2MP services).
+
+5.  Reoptimization and Modification
+
+   Once established, P2MP LSPs are more sensitive to modification than
+   their P2P counterparts.  If an egress is removed from a P2P LSP, the
+   whole LSP is torn down.  But egresses may be added to and removed
+   from active P2MP LSPs as receivers come and go.
+
+   The removal of an egress from a P2MP LSP does not require any new
+   path computation since the tree can be automatically pruned.
+
+   The addition of a new egress to a P2MP LSP can be handled as the
+   computation of an appropriate branch point and the determination of a
+   P2P path from the branch point to the new egress.  This is a
+   relatively simple computation and can be achieved by reverse-path
+   CSPF, much as in the manner of some multicast IP routing protocols.
+
+   However, repeated addition to and removal from a P2MP LSP will almost
+   certainly leave it in a sub-optimal state.  The tree shape that was
+   optimal for the original set of destinations will be distorted by the
+   changes and will not be optimal for the new set of destinations.
+
+
+
+
+
+
+Yasukawa & Farrel            Informational                      [Page 9]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+   Further, as resource availability changes in the network due to other
+   LSPs being released or network resources being brought online, the
+   path of the P2MP LSP may become sub-optimal.
+
+   Computing a new optimal path for the P2MP LSP is as simple as
+   computing any optimal P2MP path, but selecting a path that can be
+   applied within the network as a migration from the existing LSP may
+   be more complex.  Additional constraints may be applied by the
+   network administrator so that only subsets of the egresses (or
+   subtrees of the P2MP tree) are optimized at any time.  In these
+   cases, the computational load of reoptimization may be considerable,
+   but fortunately reoptimization computations may be performed as
+   background activities.  Splitting the P2MP tree into subtrees, as
+   described in Section 3, may further reduce the computation load and
+   may assist with administrative preferences for partial tree
+   reoptimization.
+
+   Network-wide reoptimization of multiple LSPs [RFC5557] can achieve
+   far greater improvements in optimality within overloaded networks
+   than can be achieved by reoptimizing LSPs sequentially.  Such
+   computation would typically be performed offline and would usually
+   require a dedicated processor such as a PCE invoked by the NMS.
+
+6.  Repair
+
+   LSP repair is necessary when a network fault disrupts the ability of
+   the LSP to deliver data to an egress.  For a P2MP LSP, a network
+   fault is (statistically) likely to only impact a small subset of the
+   total set of egresses.  Repair activity, therefore, does not need to
+   recompute the path of the entire P2MP tree.  Rather, it needs to
+   quickly find suitable new branches that can be grafted onto the
+   existing tree to reconnect the disconnected leaves.
+
+   In fact, immediately after a network failure there may be a very
+   large number of path computations required in order to restore
+   multiple P2P and P2MP LSPs.  The PCEs will be heavily loaded, and it
+   is important that computation requests are restricted to only the
+   'essential'.
+
+   In this light, it is useful to note that the simple repair
+   computations described in the first paragraph of this section may be
+   applied to achieve a first repair of the LSPs, while more
+   sophisticated reoptimization computations can be deferred until the
+   network is stable and the load on the PCEs has been reduced.  Those
+   reoptimizations can be computed as described in Section 5.
+
+
+
+
+
+
+Yasukawa & Farrel            Informational                     [Page 10]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+7.  Disjoint Paths
+
+   Disjoint paths are required for end-to-end protection services and
+   sometimes for load balancing.  They may require to be fully disjoint
+   (except at the ingress and egress!), link disjoint (allowing common
+   nodes on the paths), or best-effort disjoint (allowing shared links
+   or nodes when no other path can be found).
+
+   It is possible to compute disjoint paths sequentially, but this can
+   lead to blocking problems where the second path cannot be placed.
+   Such issues are more readily avoided if the paths are computed in
+   parallel.
+
+   The computation of link disjoint P2P paths may be non-trivial and may
+   be the sort of task that an LSR offloads to a PCE because of its
+   complexity.  The computation of disjoint P2MP paths is considerably
+   more difficult and is therefore a good candidate to be offloaded to a
+   PCE that has dedicated resources.  In fact, it may well be the case
+   that not all P2MP-capable PCEs can handle disjoint path requests and
+   it may be necessary to select between PCEs based on their
+   capabilities.
+
+8.  Manageability Considerations
+
+   The use of PCE to compute P2MP paths has many of the same
+   manageability considerations as when it is used for P2P LSPs
+   [RFC5440].  There may be additional manageability implications for
+   the size of P2MP computation requests and the additional loading
+   exerted on the PCEs.
+
+8.1.  Control of Function and Policy
+
+   As already described, individual PCEs may choose to not be capable of
+   P2MP computation, and where this function is available, it may be
+   disabled by an operator, or may be automatically withdrawn when the
+   PCE becomes loaded or based on other policy considerations.
+
+   Further, a PCE may refuse any P2MP computation request or pass it on
+   to another PCE based on policy.
+
+8.2.  Information and Data Models
+
+   P2MP computation requests necessitate considerably more information
+   exchange between the LSR and the PCE than is required for P2P
+   computations.  This will result in much larger data sets to be
+   controlled and modeled, and will impact the utility of any management
+   data models, such as MIB modules.  Care needs to be taken in the
+
+
+
+
+Yasukawa & Farrel            Informational                     [Page 11]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+   design of such data models, and the use of other management protocols
+   and data modeling structures, such as NETCONF [RFC4741] and the
+   NETCONF Data Modeling Language (NETMOD), could be considered.
+
+8.3.  Liveness Detection and Monitoring
+
+   PCE liveness detection and monitoring is unchanged from P2P
+   operation, but it should be noted that P2MP requests will take longer
+   to process than P2P requests, meaning that the time between request
+   and response will be, on average, longer.  This increases the chance
+   of a communications failure between request and response and means
+   that liveness detection is more important.
+
+8.4.  Verifying Correct Operation
+
+   Correct operation of any communication between LSRs and PCEs is
+   exactly as important as it is for P2P computations.
+
+   The correct operation of path computation algorithms implemented at
+   PCEs is out of scope, but LSRs that are concerned that PCE algorithms
+   might not be operating correctly may make identical requests to
+   separate PCEs and compare the responses.
+
+8.5.  Requirements on Other Protocols and Functional Components
+
+   As is clear from the PCE architecture, a communications protocol is
+   necessary to allow LSRs to send computation requests to PCEs and for
+   PCEs to cooperate.  Requirements for such a protocol to handle P2P
+   path computations are described in [RFC4657], and additional
+   requirements in support of P2MP computations are described in
+   [PCE-P2MP].  The PCE Communication Protocol (PCEP) is defined in
+   [RFC5440], but extensions will be necessary to support P2MP
+   computation requests.
+
+   As described in the body of this document, LSRs need to be able to
+   recognize which PCEs can perform P2MP computations.  Capability
+   advertisement is already present in the PCE Discovery protocols
+   ([RFC5088] and [RFC5089]) and can also be exchanged in PCEP
+   ([RFC5440]), but extensions will be required to describe P2MP
+   capabilities.
+
+   As also described in this document, the PCE needs to know the branch
+   capabilities of the LSRs and store this information in the TED.  This
+   information can be distributed using the routing protocols as
+   described in [RFC5073].
+
+
+
+
+
+
+Yasukawa & Farrel            Informational                     [Page 12]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+8.6.  Impact on Network Operation
+
+   The use of a PCE to perform P2MP computations may have a beneficial
+   impact on network operation if it can offload processing from the
+   LSRs, freeing them up to handle protocol operations.
+
+   Furthermore, the use of a PCE may enable more dynamic behavior in
+   P2MP LSPs (such as the addition of new egresses, reoptimization, and
+   failure recovery) than is possible using more traditional
+   management-based planning techniques.
+
+9.  Security Considerations
+
+   The use of PCE to compute P2MP paths does not raise any additional
+   security issues beyond those that generally apply to the PCE
+   architecture.  See [RFC4655] for a full discussion.
+
+   Note, however, that P2MP computation requests are more CPU-intensive
+   and also use more link bandwidth.  Therefore, if the PCE was attacked
+   by the injection of spurious path computation requests, it would be
+   more vulnerable through a smaller number of such requests.
+
+   Thus, the use of message integrity and authentication mechanisms
+   within the PCE protocol should be used to mitigate attacks from
+   devices that are not authorized to send requests to the PCE.  It
+   would be possible to consider applying different authorization
+   policies for P2MP path computation requests compared to other
+   requests.
+
+10.  Acknowledgments
+
+   The authors would like to thank Jerry Ash and Jean-Louis Le Roux for
+   their thoughtful comments.  Lars Eggert, Dan Romascanu, and Tim Polk
+   provided useful comments during IESG review.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+              Computation Element (PCE)-Based Architecture", RFC 4655,
+              August 2006.
+
+11.2.  Informative References
+
+   [RFC4461]  Yasukawa, S., Ed., "Signaling Requirements for Point-to-
+              Multipoint Traffic-Engineered MPLS Label Switched Paths
+              (LSPs)", RFC 4461, April 2006.
+
+
+
+Yasukawa & Farrel            Informational                     [Page 13]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+   [RFC4657]  Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
+              Element (PCE) Communication Protocol Generic
+              Requirements", RFC 4657, September 2006.
+
+   [RFC4741]  Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741,
+              December 2006.
+
+   [RFC4834]  Morin, T., Ed., "Requirements for Multicast in Layer 3
+              Provider-Provisioned Virtual Private Networks (PPVPNs)",
+              RFC 4834, April 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.
+
+   [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.
+
+   [RFC5394]  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
+              "Policy-Enabled Path Computation Framework", RFC 5394,
+              December 2008.
+
+   [RFC5440]  Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
+              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+              March 2009.
+
+   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
+              "A Backward-Recursive PCE-Based Computation (BRPC)
+              Procedure to Compute Shortest Constrained Inter-Domain
+              Traffic Engineering Label Switched Paths", RFC 5441, April
+              2009.
+
+   [RFC5557]  Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
+              Computation Element Communication Protocol (PCEP)
+              Requirements and Protocol Extensions in Support of Global
+              Concurrent Optimization", RFC 5557, July 2009.
+
+
+
+
+Yasukawa & Farrel            Informational                     [Page 14]
+
+RFC 5671             PCE for P2MP MPLS and GMPLS TE         October 2009
+
+
+   [PCE-P2MP] Yasukawa, S., and Farrel, A., "PCC-PCE Communication
+              Requirements for Point to Multipoint Multiprotocol Label
+              Switching Traffic Engineering (MPLS-TE)", Work in
+              Progress, May 2008.
+
+Authors' Addresses
+
+   Seisho Yasukawa
+   NTT Corporation
+   9-11, Midori-Cho 3-Chome
+   Musashino-Shi, Tokyo 180-8585,
+   Japan
+
+   EMail: yasukawa.seisho@lab.ntt.co.jp
+
+
+   Adrian Farrel
+   Old Dog Consulting
+
+   EMail: adrian@olddog.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yasukawa & Farrel            Informational                     [Page 15]
+