draft-ietf-pce-p2mp-req-02.txt   draft-ietf-pce-p2mp-req-03.txt 
Network Working Group S. Yasukawa Network Working Group S. Yasukawa
Internet Draft NTT Internet Draft NTT
Category: Informational A. Farrel Category: Informational A. Farrel
Created: August 20, 2009 Old Dog Consulting Created: October 16, 2009 Old Dog Consulting
Expires: February 20, 2010 Expires: April 16, 2010
PCC-PCE Communication Requirements for Point to Multipoint PCC-PCE Communication Requirements for Point to Multipoint
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
draft-ietf-pce-p2mp-req-02.txt draft-ietf-pce-p2mp-req-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 "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 and
presents a detailed set of PCC-PCE communication protocol 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.
Conventions used in this document Conventions used in this document
Although this document is not a protocol specification, the key words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be document are to be interpreted as described in RFC 2119 [RFC2119].
interpreted as described in RFC 2119 [RFC2119] for clarity of Although this document is not a protocol specification, this
description of requirements. convention is adopted for clarity of description of requirements.
1. Introduction 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.
skipping to change at page 3, line 9 skipping to change at page 3, line 9
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 2.1.1. Indication of P2MP Path Computation Request
Although the presence of certain parameters (such as a list of more R1: Although the presence of certain parameters (such as a list of
than one destination) MAY be used by a protocol specification to more than one destination) MAY be used by a protocol
allow an implementation to infer that a path computation request is specification to allow an implementation to infer that a path
for a P2MP LSP, an explicit parameter SHOULD be placed in a computation request is for a P2MP LSP, an explicit parameter
conspicuous place within a Path Computation Request message to allow SHOULD be placed in a conspicuous place within a Path
a receiving PCE to easily identify that the request is for a P2MP Computation Request message to allow a receiving PCE to easily
path. identify that the request is for a P2MP path.
2.1.2. Indication of P2MP Objective Functions 2.1.2. Indication of P2MP Objective Functions
[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 computation. objective functions to be applied by a PCE during path
computation.
This document makes no change to that requirement, but it should be This document makes no change to that requirement, but it should
noted that new and different objective functions will be used for be noted that new and different objective functions will be used
P2MP computation. Definitions for core objective functions can be for P2MP computation. Definitions for core objective functions
found in [RFC5541] together with usage procedures. New objective can be found in [RFC5541] together with usage procedures. New
functions for use with P2MP path computations will need to be objective functions for use with P2MP path computations will
defined and allocated codepoints in a separate document. need to be defined and allocated codepoints in a separate
document.
2.1.3. Non-Support of P2MP Path Computation 2.1.3. Non-Support of P2MP Path Computation
PCEs are not required to support P2MP path computation. Therefore, it R3: PCEs are not required to support P2MP path computation.
MUST be possible for a PCE to reject a P2MP Path Computation Request Therefore, it MUST be possible for a PCE to reject a P2MP Path
message with a reason code that indicates no support for P2MP path Computation Request message with a reason code that indicates no
computation. support for P2MP path computation.
2.1.4. Non-Support by Back-Level PCE Implementations 2.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 2.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 code described in Section 2.1.3. reason code described in Section 2.1.3.
Therefore, at least one parameter required for inclusion in a P2MP R4: Therefore, at least one parameter required for inclusion in a
Path Computation Request message MUST be defined in such a way as to P2MP Path Computation Request message MUST be defined in such a
cause automatic rejection as unprocessable or unrecognized by a back- way as to cause automatic rejection as unprocessable or
level PCE implementation without requiring any changes to that PCE. unrecognized by a back-level PCE implementation without
It is RECOMMENDED that the parameter that causes this result is the requiring any changes to that PCE. It is RECOMMENDED that the
parameter described in Section 2.1.1. parameter that causes this result is the parameter described in
Section 2.1.1.
2.1.5. Specification of Destinations 2.1.5. Specification of Destinations
Since P2MP LSPs have more than one destination, it MUST be possible R5: Since P2MP LSPs have more than one destination, it MUST be
for a single Path Computation Request to list multiple destinations. possible for a single Path Computation Request to list multiple
destinations.
2.1.6. Indication of P2MP Paths 2.1.6. Indication of P2MP Paths
The Path Computation Response MUST be able to carry the path of a R6: The Path Computation Response MUST be able to carry the path of
P2MP LSP. a P2MP LSP.
P2MP paths can be expressed as a compacted series of routes as P2MP paths can be expressed as a compacted 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 to
carry the P2MP path as either a compacted path (but not necessarily carry the P2MP path as either a compacted path (but not necessarily
using the identical encoding as described in [RFC4875]), or as a using the identical encoding as described in [RFC4875]), or as a non-
non-compacted path comprising a series of source-to-leaf point-to- compacted path comprising a series of source-to-leaf point-to-point
point (P2P) paths (known as S2L sub-paths). (P2P) paths (known as S2L sub-paths).
By default, the path returned by the PCE SHOULD use the compacted R7: By default, the path returned by the PCE SHOULD use the
format. compacted format.
The request from the PCC MAY allow the PCC to express a preference The request from the PCC MAY allow the PCC to express a
for receiving a compacted or non-compacted P2MP path in the response. preference for receiving a compacted or non-compacted P2MP path
in the response.
2.1.7. Multi-Message Requests and Responses 2.1.7. Multi-Message Requests and Responses
A single P2MP LSP may have very many destinations, and the computed R8: A single P2MP LSP may have very many destinations, and the
path (tree) may be very extensive. In these cases it is possible that computed path (tree) may be very extensive. In these cases it is
the entire Path Computation Request or Response cannot fit within one possible that the entire Path Computation Request or Response
PCE message. Therefore, it MUST be possible for a single request or cannot fit within one PCE message. Therefore, it MUST be
response to be conveyed by a sequence of PCE messages. possible for a single request or response to be conveyed by a
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 2.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.
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 2.1.9. Path Modification and Path Diversity
No changes are made to the requirement to support path modification R10: No changes are made to the requirement to support path
and path diversity as described in [RFC4657]. Note, however, that a modification and path diversity as described in [RFC4657]. Note,
consequence of this requirement is that it MUST be possible to supply however, that a consequence of this requirement is that it MUST
an existing path on a Path Computation Request. This requirement is be possible to supply an existing path on a Path Computation
unchanged from [RFC4657], but it is a new requirement that such paths Request. This requirement is unchanged from [RFC4657], but it is
MUST be able to be P2MP paths. The PCC MUST be able to supply these a new requirement that such paths MUST be able to be P2MP paths.
paths as compacted paths or as a non-compacted paths (see Section The PCC MUST be able to supply these paths as compacted paths or
2.1.6) according to the preference of the PCC. as a non-compacted paths (see Section 2.1.6) according to the
preference of the PCC.
2.1.10. Reoptimization of P2MP TE LSPs 2.1.10. Reoptimization of P2MP TE LSPs
Reoptimization MUST be supported for P2MP TE LSPs as described for R11: Reoptimization MUST be supported for P2MP TE LSPs as described
P2P LSPs in [RFC4657]. To support this, the existing path MUST be for P2P LSPs in [RFC4657]. To support this, the existing path
supplied as described in Section 2.1.9. MUST be supplied as described in Section 2.1.9.
Because P2MP LSPs are more complex it is often the case that small Because P2MP LSPs are more complex it is often the case that
optimization improvements can be made after changes in network small optimization improvements can be made after changes in
resource availability. But re-signaling any LSP introduces risks to network resource availability. But re-signaling any LSP
the stability of the service provided to the customer and the introduces risks to the stability of the service provided to the
stability of the network even when techniques like make-before-break customer and the stability of the network even when techniques
[RFC3209] are used. Therefore, a P2MP Path Computation Request SHOULD like make-before-break [RFC3209] are used. Therefore, a P2MP
contain a parameter that allows the PCC to express a cost-benefit Path Computation Request SHOULD contain a parameter that allows
reoptimization threshold for the whole LSP as well as per the PCC to express a cost-benefit reoptimization threshold for
destination. The setting of this parameter is subject to local policy the whole LSP as well as per destination. The setting of this
at the PCC and SHOULD be subject to policy at the PCE [RFC5394]. parameter is subject to local policy at the PCC and SHOULD be
subject to policy at the PCE [RFC5394].
Path reoptimization responses SHOULD indicate which of the routes (as Path reoptimization responses SHOULD indicate which of the
supplied according to Section 2.1.6) have been modified from the routes (as supplied according to Section 2.1.6) have been
paths supplied on the request. modified from the paths supplied on the request.
2.1.11. Addition and Removal of Destinations from Existing Paths 2.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 2.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.
To support this function for leaf additions it MUST be possible to R12: To support this function for leaf additions it MUST be possible
make the following indications on a path computation request: to make the following indications on a path computation request:
- The path of an existing P2MP LSP (as described in Section 2.1.9). - The path of an existing P2MP LSP (as described in Section
2.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 paths - Which destinations of the existing tree must not have their
modified. paths modified.
It MAY also be possible to indicate on a path computation request a It MAY also be possible to indicate on a path computation
cost-benefit reoptimization threshold such that the tree and/or a new request a cost-benefit reoptimization threshold such that the
path to any individual destination is not supplied unless a certain addition of new leaves will not cause reoptimization of the
improvement is made. Compare with Section 2.1.10. existing P2MP tree unless a certain improvement is made over
simply grafting the new leaves to the existing tree. (Compare
with Section 2.1.10.)
In the case of the deletion of one or more destinations, it is not In the case of the deletion of one or more destinations, it is
necessary to compute a new path for the P2MP TE LSP, but such a not necessary to compute a new path for the P2MP TE LSP, but
computation may yield optimizations over a simple pruning of the such a computation may yield optimizations over a simple pruning
tree. The recomputation function in this case is essentially the same of the tree. The recomputation function in this case is
as that described in Section 2.1.10, but note that it MAY be possible essentially the same as that described in Section 2.1.10, but
to supply the full previous path of the entire P2MP TE LSP (that is, note that it MAY be possible to supply the full previous path of
before the deletion of the destinations) on the Path Computation the entire P2MP TE LSP (that is, before the deletion of the
Request. destinations) on the Path Computation Request.
For both addition and deletion of destinations, the Path Computation For both addition and deletion of destinations, the Path
Response SHOULD indicate which of the routes (as supplied according Computation Response SHOULD indicate which of the routes (as
to Section 2.1.6) have been modified from the paths supplied on the supplied according to Section 2.1.6) have been modified from the
request as described in Section 2.1.10. paths supplied on the request as described in Section 2.1.10.
Note that the selection of all of these options is subject to local Note that the selection of all of these options is subject to
policy at the PCC, and SHOULD be subject to policy at the PCE local policy at the PCC, and SHOULD be subject to policy at the
[RFC5394]. PCE [RFC5394].
2.1.12. Specification of Applicable Branch Nodes 2.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. That is, to provide to
the path computation a limiting set of nodes that can be used as the path computation a limiting set of nodes that can be used as
branches for a P2MP path computation, or to provide a list of nodes branches for a P2MP path computation, or to provide a list of nodes
that must not be used as branch points. that must not be used as branch points.
The PCC MUST be able to specify on a Path Computation Request a list R13: The PCC MUST be able to specify on a Path Computation Request a
of nodes that constitutes a limiting superset of the branch nodes for list of nodes that constitutes a limiting superset of the branch
a P2MP path computation. nodes for a P2MP path computation.
A PCC MUST be able to specify on a Path Computation Request a list of A PCC MUST be able to specify on a Path Computation Request a
nodes that must not be used as branch nodes for a P2MP path list of nodes that must not be used as branch nodes for a P2MP
computation. path computation.
2.1.13. Capabilities Exchange 2.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].
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 ability to perform P2MP
computation is not advertised as part of PCE discovery, the PCECP computation is not advertised as part of PCE discovery, the
MUST allow a PCC to discover which PCEs with which it communicates PCECP MUST allow a PCC to discover which PCEs with which it
support P2MP path computation and which objective functions specific communicates support P2MP path computation and which objective
to P2MP path computation are supported by each PCE. functions specific to P2MP path computation are supported by
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 2.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
Section 2.1.9 sets out the requirement to be able to request multiple
diverse paths. Additionally, with P2MP trees it may be that only
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
P2MP path tree with partial path diversity for specific leaves
or a specific S2L sub-path.
3. Manageability Considerations 3. Manageability Considerations
3.1. Control of Function and Policy 3.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 2.1.13.
Support for, and advertisement of support for, P2MP MPLS TE path Support for, and advertisement of support for, P2MP MPLS TE path
skipping to change at page 9, line 17 skipping to change at page 9, line 31
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 5. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
6. Acknowledgments 6. Acknowledgments
Thanks to Dean Cheng, Young Lee, Quintin Zhao, and Daniel King for Thanks to Dean Cheng, Young Lee, Quintin Zhao, Daniel King, and
their comments and suggestions on this document. Fabien Verhaeghe for their comments and suggestions on this document.
7. References 7. References
7.1. Normative Reference 7.1. Normative Reference
[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. requirements levels", RFC 2119, March 1997.
[RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element [RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element
(PCE) Communication Protocol Generic Requirements", (PCE) Communication Protocol Generic Requirements",
 End of changes. 32 change blocks. 
116 lines changed or deleted 138 lines changed or added

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