draft-ietf-pce-p2mp-req-05.txt   rfc5862.txt 
Network Working Group S. Yasukawa
Internet Draft NTT
Category: Informational A. Farrel
Created: January 29, 2010 Old Dog Consulting
Expires: July 29, 2010
PCC-PCE Communication Requirements for Point to Multipoint Internet Engineering Task Force (IETF) S. Yasukawa
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Request for Comments: 5862 NTT Corporation
Category: Informational A. Farrel
ISSN: 2070-1721 Old Dog Consulting
June 2010
draft-ietf-pce-p2mp-req-05.txt Path Computation Clients (PCC) - Path Computation Element (PCE)
Requirements for Point-to-Multipoint MPLS-TE
Abstract Abstract
The Path Computation Element (PCE) provides path computation The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multi-Protocol Label functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks. Switching (MPLS) and Generalized MPLS (GMPLS) networks.
Extensions to the MPLS and GMPLS signaling and routing protocols have Extensions to the MPLS and GMPLS signaling and routing protocols have
been made in support of point-to-multipoint (P2MP) Traffic Engineered been made in support of point-to-multipoint (P2MP) Traffic Engineered
(TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is
already established, and since P2MP TE LSP routes are sometimes already established, and since P2MP TE LSP routes are sometimes
complex to compute, it is likely that PCE will be used for P2MP LSPs. complex to compute, it is likely that PCE will be used for P2MP LSPs.
Generic requirements for a communication protocol between Path Generic requirements for a communication protocol between Path
Computation Clients (PCCs) and PCEs are presented in "Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path
Computation Element (PCE) Communication Protocol Generic Computation Element (PCE) Communication Protocol Generic
Requirements". This document complements the generic requirements and Requirements". This document complements the generic requirements
presents a detailed set of PCC-PCE communication protocol and presents a detailed set of PCC-PCE communication protocol
requirements for point-to-multipoint MPLS/GMPLS traffic engineering. requirements for point-to-multipoint MPLS/GMPLS traffic engineering.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document is not an Internet Standards Track specification; it is
and may be updated, replaced, or obsoleted by other documents at any published for informational purposes.
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt. (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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5862.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Conventions used in this document 1. Introduction
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].
Although this document is not a protocol specification, this
convention is adopted for clarity of description of requirements.
1. Introduction
The Path Computation Element (PCE) defined in [RFC4655] is an entity The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a that is capable of computing a network path or route based on a
network graph, and applying computational constraints. The intention network graph, and applying computational constraints. The intention
is that the PCE is used to compute the path of Traffic Engineered is that the PCE is used to compute the path of Traffic Engineered
Label Switched Paths (TE LSPs) within Multiprotocol Label Switching Label Switched Paths (TE LSPs) within Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) networks. (MPLS) and Generalized MPLS (GMPLS) networks.
Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are
documented in [RFC4461] and signaling protocol extensions for documented in [RFC4461], and signaling protocol extensions for
setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE
networks are considered in support of various features including networks are considered in support of various features, including
layer 3 multicast virtual private networks [RFC4834]. layer 3 multicast virtual private networks [RFC4834].
Path computation for P2MP TE LSPs presents a significant challenge, Path computation for P2MP TE LSPs presents a significant challenge,
and network optimization of multiple P2MP TE LSPs requires and network optimization of multiple P2MP TE LSPs requires
considerable computational resources. PCE offers a way to offload considerable computational resources. PCE offers a way to offload
such path computations from Label Switching Routers (LSRs). such path computations from Label Switching Routers (LSRs).
The applicability of the PCE-based path computation architecture to The applicability of the PCE-based path computation architecture to
P2MP MPLS TE is described in a companion document [RFC5671]. No P2MP MPLS TE is described in a companion document [RFC5671]. No
further attempt is made to justify the use of PCE for P2MP MPLS TE further attempt is made to justify the use of PCE for P2MP MPLS TE
within this document. within this document.
This document presents a set of PCC-PCE communication protocol This document presents a set of PCC-PCE communication protocol
(PCECP) requirements for P2MP MPLS traffic engineering. It (PCECP) requirements for P2MP MPLS traffic engineering. It
supplements the generic requirements documented in [RFC4657]. supplements the generic requirements documented in [RFC4657].
2. PCC-PCE Communication Requirements for P2MP MPLS Traffic Engineering 2. Conventions Used in This Document
This section sets out additional requirements not covered in The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
[RFC4657] specific to P2MP MPLS TE. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Although this document is not a protocol specification, this
convention is adopted for clarity of description of requirements.
2.1. PCC-PCE Communication 3. PCC-PCE Communication Requirements for P2MP MPLS Traffic Engineering
This section sets out additional requirements specific to P2MP MPLS
TE that are not covered in [RFC4657].
3.1. PCC-PCE Communication
The PCC-PCE communication protocol MUST allow requests and replies The PCC-PCE communication protocol MUST allow requests and replies
for the computation of paths for P2MP LSPs. for the computation of paths for P2MP LSPs.
This requires no additional messages, but requires the addition of This requires no additional messages, but requires the addition of
the parameters described in the following sections to the existing the parameters described in the following sections to the existing
PCC-PCE communication protocol messages. PCC-PCE communication protocol messages.
2.1.1. Indication of P2MP Path Computation Request 3.1.1. Indication of P2MP Path Computation Request
R1: Although the presence of certain parameters (such as a list of R1: Although the presence of certain parameters (such as a list of
more than one destination) MAY be used by a protocol more than one destination) MAY be used by a protocol
specification to allow an implementation to infer that a path specification to allow an implementation to infer that a Path
computation request is for a P2MP LSP, an explicit parameter Computation Request is for a P2MP LSP, an explicit parameter
SHOULD be placed in a conspicuous place within a Path SHOULD be placed in a conspicuous place within a Path
Computation Request message to allow a receiving PCE to easily Computation Request message to allow a receiving PCE to easily
identify that the request is for a P2MP path. identify that the request is for a P2MP path.
2.1.2. Indication of P2MP Objective Functions 3.1.2. Indication of P2MP Objective Functions
R2: [RFC4657] includes the requirement to be able to specify the R2: [RFC4657] includes the requirement to be able to specify the
objective functions to be applied by a PCE during path objective functions to be applied by a PCE during path
computation. computation.
This document makes no change to that requirement, but it should This document makes no change to that requirement, but it should
be noted that new and different objective functions will be used be noted that new and different objective functions will be used
for P2MP computation. Definitions for core objective functions for P2MP computation. Definitions for core objective functions
can be found in [RFC5541] together with usage procedures. New can be found in [RFC5541] together with usage procedures. New
objective functions for use with P2MP path computations will objective functions for use with P2MP path computations will
need to be defined and allocated codepoints in a separate need to be defined and allocated codepoints in a separate
document. document.
2.1.3. Non-Support of P2MP Path Computation 3.1.3. Non-Support of P2MP Path Computation
R3: PCEs are not required to support P2MP path computation. R3: PCEs are not required to support P2MP path computation.
Therefore, it MUST be possible for a PCE to reject a P2MP Path Therefore, it MUST be possible for a PCE to reject a P2MP Path
Computation Request message with a reason code that indicates no Computation Request message with a reason code that indicates no
support for P2MP path computation. support for P2MP path computation.
2.1.4. Non-Support by Back-Level PCE Implementations 3.1.4. Non-Support by Back-Level PCE Implementations
It is possible that initial PCE implementations will be developed It is possible that initial PCE implementations will be developed
without support for P2MP path computation and without the ability to without support for P2MP path computation and without the ability to
recognize the explicit parameter described in section 2.1.1. Such recognize the explicit parameter described in Section 3.1.1. Such
legacy implementations will not be able to make use of the new legacy implementations will not be able to make use of the new reason
reason code described in Section 2.1.3. code described in Section 3.1.3.
R4: Therefore, at least one parameter required for inclusion in a R4: Therefore, at least one parameter required for inclusion in a
P2MP Path Computation Request message MUST be defined in such a P2MP Path Computation Request message MUST be defined in such a
way as to cause automatic rejection as unprocessable or way as to cause automatic rejection as unprocessable or
unrecognized by a back-level PCE implementation without unrecognized by a back-level PCE implementation without
requiring any changes to that PCE. It is RECOMMENDED that the requiring any changes to that PCE. It is RECOMMENDED that the
parameter that causes this result is the parameter described in parameter that causes this result be the parameter described in
Section 2.1.1. Section 3.1.1.
2.1.5. Specification of Destinations 3.1.5. Specification of Destinations
R5: Since P2MP LSPs have more than one destination, it MUST be R5: Since P2MP LSPs have more than one destination, it MUST be
possible for a single Path Computation Request to list multiple possible for a single Path Computation Request to list multiple
destinations. destinations.
2.1.6. Indication of P2MP Paths 3.1.6. Indication of P2MP Paths
R6: The Path Computation Response MUST be able to carry the path of R6: The Path Computation Response MUST be able to carry the path of
a P2MP LSP. a P2MP LSP.
P2MP paths can be expressed as a compressed series of routes as P2MP paths can be expressed as a compressed series of routes as
described in [RFC4875]. The Path Computation Response MUST be able to described in [RFC4875]. The Path Computation Response MUST be able
carry the P2MP path as either a compressed path (but not necessarily to carry the P2MP path as either a compressed path (but not
using the identical encoding as described in [RFC4875]), or as a non- necessarily using the identical encoding as described in [RFC4875]),
compressed path comprising a series of source-to-leaf point-to-point or as a non-compressed path comprising a series of source-to-leaf
(P2P) paths (known as S2L sub-paths). point-to-point (P2P) paths (known as S2L sub-paths).
R7: By default, the path returned by the PCE SHOULD use the R7: By default, the path returned by the PCE SHOULD use the
compressed format. compressed format.
The request from the PCC MAY allow the PCC to express a The request from the PCC MAY allow the PCC to express a
preference for receiving a compressed or non-compressed P2MP preference for receiving a compressed or non-compressed P2MP
path in the response. path in the response.
2.1.7. Multi-Message Requests and Responses 3.1.7. Multi-Message Requests and Responses
R8: A single P2MP LSP may have very many destinations, and the R8: A single P2MP LSP may have many destinations, and the computed
computed path (tree) may be very extensive. In these cases it is path (tree) may be very extensive. In these cases, it is
possible that the entire Path Computation Request or Response possible that the entire Path Computation Request or Response
cannot fit within one PCE message. Therefore, it MUST be cannot fit within one PCE message. Therefore, it MUST be
possible for a single request or response to be conveyed by a possible for a single request or response to be conveyed by a
sequence of PCE messages. sequence of PCE messages.
Note that there is a requirement in [RFC4657] for reliable and Note that there is a requirement in [RFC4657] for reliable and
in-order message delivery, so it is assumed that components of the in-order message delivery, so it is assumed that components of the
sequence will be delivered in order and without missing components. sequence will be delivered in order and without missing components.
2.1.8. Non-Specification of Per-Destination Constraints and Parameters 3.1.8. Non-Specification of Per-Destination Constraints and Parameters
[RFC4875] requires that all branches of a single P2MP LSP have the [RFC4875] requires that all branches of a single P2MP LSP have the
same characteristics, and achieves this by not allowing the signaling same characteristics, and achieves this by not allowing the signaling
parameters to be varied for different branches of the same P2MP LSP. parameters to be varied for different branches of the same P2MP LSP.
R9: It MUST NOT be possible to set different constraints, traffic R9: It MUST NOT be possible to set different constraints, traffic
parameters, or quality of service requirements for different parameters, or quality-of-service requirements for different
destinations of a P2MP LSP within a single computation request. destinations of a P2MP LSP within a single computation request.
2.1.9. Path Modification and Path Diversity 3.1.9. Path Modification and Path Diversity
R10: No changes are made to the requirement to support path R10: No changes are made to the requirement to support path
modification and path diversity as described in [RFC4657]. Note, modification and path diversity as described in [RFC4657].
however, that a consequence of this requirement is that it MUST Note, however, that a consequence of this requirement is that it
be possible to supply an existing path on a Path Computation MUST be possible to supply an existing path in a Path
Request. This requirement is unchanged from [RFC4657], but it is Computation Request. This requirement is unchanged from
a new requirement that such paths MUST be able to be P2MP paths. [RFC4657], but it is a new requirement that such paths MUST be
The PCC MUST be able to supply these paths as compressed paths able to be P2MP paths. The PCC MUST be able to supply these
or as a non-compressed paths (see Section 2.1.6) according to paths as compressed paths or as non-compressed paths (see
the preference of the PCC. Section 3.1.6) according to the preference of the PCC.
2.1.10. Reoptimization of P2MP TE LSPs 3.1.10. Reoptimization of P2MP TE LSPs
R11: Reoptimization MUST be supported for P2MP TE LSPs as described R11: Reoptimization MUST be supported for P2MP TE LSPs as described
for P2P LSPs in [RFC4657]. To support this, the existing path for P2P LSPs in [RFC4657]. To support this, the existing path
MUST be supplied as described in Section 2.1.9. MUST be supplied as described in Section 3.1.9.
Because P2MP LSPs are more complex it is often the case that Because P2MP LSPs are more complex, it is often the case that
small optimization improvements can be made after changes in small optimization improvements can be made after changes in
network resource availability. But re-signaling any LSP network resource availability. However, re-signaling any LSP
introduces risks to the stability of the service provided to the introduces risks to the stability of the service provided to the
customer and the stability of the network even when techniques customer and the stability of the network, even when techniques
like make-before-break [RFC3209] are used. Therefore, a P2MP like make-before-break [RFC3209] are used. Therefore, a P2MP
Path Computation Request SHOULD contain a parameter that allows Path Computation Request SHOULD contain a parameter that allows
the PCC to express a cost-benefit reoptimization threshold for the PCC to express a cost-benefit reoptimization threshold for
the whole LSP as well as per destination. The setting of this the whole LSP, as well as per destination. The setting of this
parameter is subject to local policy at the PCC and SHOULD be parameter is subject to local policy at the PCC and SHOULD be
subject to policy at the PCE [RFC5394]. subject to policy at the PCE [RFC5394].
Path reoptimization responses SHOULD indicate which of the Path reoptimization responses SHOULD indicate which of the
routes (as supplied according to Section 2.1.6) have been routes (as supplied according to Section 3.1.6) have been
modified from the paths supplied on the request. modified from the paths supplied in the request.
2.1.11. Addition and Removal of Destinations from Existing Paths 3.1.11. Addition and Removal of Destinations from Existing Paths
A variation of path modification described in Section 2.1.9 is that A variation of path modification described in Section 3.1.9 is that
destinations may be added to, or removed from, existing P2MP TE LSPs. destinations may be added to, or removed from, existing P2MP TE LSPs.
In the case of the addition of one or more destinations, it is In the case of the addition of one or more destinations, it is
necessary to compute a path for a new branch of the P2MP LSP. It may necessary to compute a path for a new branch of the P2MP LSP. It may
be desirable to recompute the whole P2MP tree, to add the new branch be desirable to recompute the whole P2MP tree, to add the new branch
as a simple spur from the existing tree, or to recompute part of the as a simple spur from the existing tree, or to recompute part of the
P2MP tree. P2MP tree.
R12: To support this function for leaf additions it MUST be possible R12: To support this function for leaf additions, it MUST be possible
to make the following indications on a path computation request: to make the following indications in a Path Computation Request:
- The path of an existing P2MP LSP (as described in Section - The path of an existing P2MP LSP (as described in
2.1.9). Section 3.1.9).
- Which destinations are new additions to the tree. - Which destinations are new additions to the tree.
- Which destinations of the existing tree must not have their - Which destinations of the existing tree must not have their
paths modified. paths modified.
It MAY also be possible to indicate on a path computation It MAY also be possible to indicate in a Path Computation
request a cost-benefit reoptimization threshold such that the Request a cost-benefit reoptimization threshold, such that the
addition of new leaves will not cause reoptimization of the addition of new leaves will not cause reoptimization of the
existing P2MP tree unless a certain improvement is made over existing P2MP tree unless a certain improvement is made over
simply grafting the new leaves to the existing tree. (Compare simply grafting the new leaves to the existing tree. (Compare
with Section 2.1.10.) with Section 3.1.10.)
In the case of the deletion of one or more destinations, it is In the case of the deletion of one or more destinations, it is
not necessary to compute a new path for the P2MP TE LSP, but not necessary to compute a new path for the P2MP TE LSP, but
such a computation may yield optimizations over a simple pruning such a computation may yield optimizations over a simple pruning
of the tree. The recomputation function in this case is of the tree. The recomputation function in this case is
essentially the same as that described in Section 2.1.10, but essentially the same as that described in Section 3.1.10, but
note that it MAY be possible to supply the full previous path of note that it MAY be possible to supply the full previous path of
the entire P2MP TE LSP (that is, before the deletion of the the entire P2MP TE LSP (that is, before the deletion of the
destinations) on the Path Computation Request. destinations) in the Path Computation Request.
For both addition and deletion of destinations, the Path For both addition and deletion of destinations, the Path
Computation Response SHOULD indicate which of the routes (as Computation Response SHOULD indicate which of the routes (as
supplied according to Section 2.1.6) have been modified from the supplied according to Section 3.1.6) have been modified from the
paths supplied on the request as described in Section 2.1.10. paths supplied in the Path Computation Request, as described in
Section 3.1.10.
Note that the selection of all of these options is subject to Note that the selection of all of these options is subject to
local policy at the PCC, and SHOULD be subject to policy at the local policy at the PCC and SHOULD be subject to policy at the
PCE [RFC5394]. PCE [RFC5394].
2.1.12. Specification of Applicable Branch Nodes 3.1.12. Specification of Applicable Branch Nodes
For administrative or security reasons, or for other policy reasons, For administrative or security reasons, or for other policy reasons,
it may be desirable to limit the set of nodes within the network that it may be desirable to limit the set of nodes within the network that
may be used as branch points for a given LSP. That is, to provide to may be used as branch points for a given LSP, i.e., to provide to the
the path computation a limiting set of nodes that can be used as path computation a limiting set of nodes that can be used as branches
branches for a P2MP path computation, or to provide a list of nodes for a P2MP path computation, or to provide a list of nodes that must
that must not be used as branch points. not be used as branch points.
R13: The PCC MUST be able to specify on a Path Computation Request a R13: The PCC MUST be able to specify in a Path Computation Request a
list of nodes that constitutes a limiting superset of the branch list of nodes that constitutes a limiting superset of the branch
nodes for a P2MP path computation. nodes for a P2MP path computation.
A PCC MUST be able to specify on a Path Computation Request a A PCC MUST be able to specify in a Path Computation Request a
list of nodes that must not be used as branch nodes for a P2MP list of nodes that must not be used as branch nodes for a P2MP
path computation. path computation.
2.1.13. Capabilities Exchange 3.1.13. Capabilities Exchange
PCE capabilities exchange forms part of PCE discovery [RFC4674], but PCE capabilities exchange forms part of PCE discovery [RFC4674], but
may also be included in the PCECP message exchanges [RFC4657]. may also be included in the PCECP message exchanges [RFC4657].
R14: The ability to perform P2MP path computation and the objective R14: The ability to perform P2MP path computation and the objective
functions supported by a PCE SHOULD be advertised as part of PCE functions supported by a PCE SHOULD be advertised as part of PCE
discovery. In the event that the PCE ability to perform P2MP discovery. In the event that the PCE's ability to perform P2MP
computation is not advertised as part of PCE discovery, the computation is not advertised as part of PCE discovery, the
PCECP MUST allow a PCC to discover which PCEs with which it PCECP MUST allow a PCC to discover which PCEs with which it
communicates support P2MP path computation and which objective communicates support P2MP path computation, and which objective
functions specific to P2MP path computation are supported by functions specific to P2MP path computation are supported by
each PCE. each PCE.
The list of objective functions is assumed to be coordinated with The list of objective functions is assumed to be coordinated with
those that can be requested as described in Section 2.1.2. those that can be requested as described in Section 3.1.2.
These requirements do not represent a change to [RFC4657] except to These requirements do not represent a change to [RFC4657], except to
add more capabilities and objective functions. add more capabilities and objective functions.
2.1.14. Path-Tree Diversity 3.1.14. Path-Tree Diversity
Section 2.1.9 sets out the requirement to be able to request multiple Section 3.1.9 sets out the requirement to be able to request multiple
diverse paths. Additionally, with P2MP trees it may be that only diverse paths. Additionally, with P2MP trees, it may be that only
parts of the tree can be, or need to be diverse. parts of the tree can be, or need to be, diverse.
R15: The PCC SHOULD be able to request a PCE to compute a secondary R15: The PCC SHOULD be able to request a PCE to compute a secondary
P2MP path tree with partial path diversity for specific leaves P2MP path tree with partial path diversity for specific leaves
or a specific S2L sub-path. or a specific S2L sub-path.
3. Manageability Considerations 4. Manageability Considerations
3.1. Control of Function and Policy 4.1. Control of Function and Policy
PCE implementations MAY provide a configuration switch to allow PCE implementations MAY provide a configuration switch to allow
support of P2MP MPLS TE computations to be enabled or disabled. When support of P2MP MPLS TE computations to be enabled or disabled. When
the level of support is changed, this SHOULD be re-advertised as the level of support is changed, this SHOULD be re-advertised as
described in Section 2.1.13. described in Section 3.1.13.
Support for, and advertisement of support for, P2MP MPLS TE path Support for, and advertisement of support for, P2MP MPLS TE path
computation MAY be subject to policy and a PCE MAY hide its P2MP computation MAY be subject to policy, and a PCE MAY hide its P2MP
capabilities from certain PCCs by not advertising them through the capabilities from certain PCCs by not advertising them through the
discovery protocol, and not reporting them to the specific PCCs in discovery protocol and not reporting them to the specific PCCs in any
any PCECP capabilities exchange. Further, a PCE MAY be directed by PCECP capabilities exchange. Further, a PCE MAY be directed by
policy to refuse a P2MP path computation for any reason including, policy to refuse a P2MP path computation for any reason including,
but not limited to, the identity of the PCC that makes the request. but not limited to, the identity of the PCC that makes the request.
3.2. Information and Data Models 4.2. Information and Data Models
PCECP protocol extensions to support P2MP MPLS TE SHOULD be PCECP protocol extensions to support P2MP MPLS TE SHOULD be
accompanied by MIB objects for the control and monitoring of the accompanied by MIB objects for the control and monitoring of the
protocol and the PCE that performs the computations. The MIB objects protocol and the PCE that performs the computations. The MIB objects
MAY be provided in the same MIB module as used for general PCECP MAY be provided in the same MIB module as used for general PCECP
control and monitoring or MAY be provided in a new MIB module. control and monitoring or MAY be provided in a new MIB module.
The MIB objects SHOULD provide the ability to control and monitor all The MIB objects SHOULD provide the ability to control and monitor all
aspects of PCECP relevant to P2MP MPLS TE path computation. aspects of PCECP relevant to P2MP MPLS TE path computation.
3.3. Liveness Detection and Monitoring 4.3. Liveness Detection and Monitoring
No changes are necessary to the liveness detection and monitoring No changes are necessary to the liveness detection and monitoring
requirements as already embodied in [RFC4657]. It should be noted, requirements as already embodied in [RFC4657]. However, it should be
however, that in general P2MP computations are likely to take longer noted that, in general, P2MP computations are likely to take longer
than P2P computations. The liveness detection and monitoring features than P2P computations. The liveness detection and monitoring
of the PCECP SHOULD take this into account. features of the PCECP SHOULD take this into account.
3.4. Verifying Correct Operation 4.4. Verifying Correct Operation
There are no additional requirements beyond those expressed in There are no additional requirements beyond those expressed in
[RFC4657] for verifying the correct operation of the PCECP. Note that [RFC4657] for verifying the correct operation of the PCECP. Note
verification of the correct operation of the PCE and its algorithms that verification of the correct operation of the PCE and its
is out of scope for the protocol requirements, but a PCC MAY send the algorithms is out of scope for the protocol requirements, but a PCC
same request to more than one PCE and compare the results. MAY send the same request to more than one PCE and compare the
results.
3.5. Requirements on Other Protocols and Functional Components 4.5. Requirements on Other Protocols and Functional Components
A PCE operates on a topology graph that may be built using A PCE operates on a topology graph that may be built using
information distributed by TE extensions to the routing protocol information distributed by TE extensions to the routing protocol
operating within the network. In order that the PCE can select a operating within the network. In order that the PCE can select a
suitable path for the signaling protocol to use to install the P2MP suitable path for the signaling protocol to use to install the P2MP
LSP, the topology graph must include information about the P2MP LSP, the topology graph must include information about the P2MP
signaling and branching capabilities of each LSR in the network. signaling and branching capabilities of each LSR in the network.
Whatever means is used to collect the information to build the Whatever means is used to collect the information to build the
topology graph, the graph MUST include the requisite information. If topology graph, the graph MUST include the requisite information. If
the TE extensions to the routing protocol are used, these SHOULD be the TE extensions to the routing protocol are used, these SHOULD be
as described in [RFC5073]. as described in [RFC5073].
3.6. Impact on Network Operation 4.6. Impact on Network Operation
The use of a PCE to compute P2MP paths is not expected to have The use of a PCE to compute P2MP paths is not expected to have
significant impact on network operations. But it should be noted that significant impact on network operations. However, it should be
the introduction of P2MP support to a PCE that already provides P2P noted that the introduction of P2MP support to a PCE that already
path computation might change the loading of the PCE significantly provides P2P path computation might change the loading of the PCE
and that might have an impact on the network behavior especially significantly, and that might have an impact on the network behavior,
during recovery periods immediately after a network failure. especially during recovery periods immediately after a network
failure.
4. Security Considerations 5. Security Considerations
P2MP computation requests do not raise any additional security issues P2MP computation requests do not raise any additional security issues
for the PCECP as there are no new messages and no new PCC-PCE for the PCECP, as there are no new messages and no new PCC-PCE
relationships or transactions introduced. relationships or transactions introduced.
Note, however, that P2MP computation requests are more CPU-intensive Note, however, that P2MP computation requests are more CPU-intensive
and also use more link bandwidth. Therefore, if the PCECP was and also use more link bandwidth. Therefore, if the PCECP was
susceptible to denial of service attacks based on the injection of susceptible to denial of service attacks based on the injection of
spurious Path Computation Requests, the support of P2MP path spurious Path Computation Requests, the support of P2MP path
computation would exacerbate the effect. computation would exacerbate the effect.
It would be possible to consider applying different authorization It would be possible to consider applying different authorization
policies for P2MP Path Computation Requests compared to other policies for P2MP Path Computation Requests compared to other
requests. requests.
5. IANA Considerations 6. Acknowledgments
This document makes no requests for IANA action.
6. Acknowledgments
Thanks to Dean Cheng, Young Lee, Quintin Zhao, Daniel King, Fabien Thanks to Dean Cheng, Young Lee, Quintin Zhao, Daniel King,
Verhaeghe, and Francis Dupont for their comments and suggestions on Fabien Verhaeghe, and Francis Dupont for their comments and
this document. suggestions on this document.
7. References 7. References
7.1. Normative Reference 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
requirements levels", RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
(PCE) Communication Protocol Generic Requirements", Element (PCE) Communication Protocol Generic
RFC 4657, September 2006. Requirements", RFC 4657, September 2006.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
J., "Policy-Enabled Path Computation Framework", "Policy-Enabled Path Computation Framework", RFC 5394,
RFC 5394, December 2008. December 2008.
[RFC5671] Yasukawa, S., and Farrel, A., "Applicability of the [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC (P2MP) MPLS and GMPLS Traffic Engineering (TE)",
5671, October 2009. RFC 5671, October 2009.
7.2. Informative Reference 7.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
LSP Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC4461] S. Yasukawa, Editor "Signaling Requirements for [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
Point-to-Multipoint Traffic Engineered MPLS LSPs", Multipoint Traffic-Engineered MPLS Label Switched Paths
RFC4461, April 2006. (LSPs)", RFC 4461, April 2006.
[RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", Computation Element (PCE)-Based Architecture", RFC 4655,
RFC 4655, August 2006. August 2006.
[RFC4674] J.L. Le Roux, Editor, "Requirements for Path [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation
Computation Element (PCE) Discovery", RFC 4674, Element (PCE) Discovery", RFC 4674, October 2006.
October 2006.
[RFC4834] Morin, T., "Requirements for Multicast in Layer 3 [RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3
Provider-Provisioned Virtual Private Networks Provider-Provisioned Virtual Private Networks (PPVPNs)",
(PPVPNs)", RFC 4834, April 2007. RFC 4834, April 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and
"Extensions to Resource Reservation Protocol - Traffic S. Yasukawa, Ed., "Extensions to Resource Reservation
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Switched Paths (LSPs)", RFC 4875, May 2007. Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
May 2007.
[RFC5073] Vasseur, J.P, and Le Roux, J.L., Editors, "IGP Routing [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing
Protocol Extensions for Discovery of Traffic Protocol Extensions for Discovery of Traffic Engineering
Engineering Node Capabilities", RFC 5073, December Node Capabilities", RFC 5073, December 2007.
2007.
[RFC5541] Le Roux, J.L., Vasseur, J.P., and Lee, Y., "Encoding [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
of Objective Functions in the Path Computation Element Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009. Communication Protocol (PCEP)", RFC 5541, June 2009.
8. Authors' Addresses Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
9-11, Midori-Cho 3-Chome 9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585, Musashino-Shi, Tokyo 180-8585
Japan JAPAN
Email: yasukawa.seisho@lab.ntt.co.jp EMail: yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
 End of changes. 110 change blocks. 
216 lines changed or deleted 208 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/