Internet Engineering Task Force (IETF) S. Yasukawa Request for Comments: 5862 NTT Corporation Category: Informational A. Farrel ISSN: 2070-1721 Old Dog Consulting June 2010 Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE
AbstractThe 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). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5862.
Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and 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. 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]. P2MP MPLS TE networks are considered in support of various features, including layer 3 multicast virtual private networks [RFC4834]. Path computation for P2MP TE LSPs presents a significant challenge, and network optimization of multiple P2MP TE LSPs requires considerable computational resources. PCE offers a way to offload such path computations from Label Switching Routers (LSRs). The applicability of the PCE-based path computation architecture to 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 within this document. This document presents a set of PCC-PCE communication protocol (PCECP) requirements for P2MP MPLS traffic engineering. It supplements the generic requirements documented in [RFC4657].
RFC2119]. Although this document is not a protocol specification, this convention is adopted for clarity of description of requirements. RFC4657]. RFC4657] includes the requirement to be able to specify the objective functions to be applied by a PCE during path computation. This document makes no change to that requirement, but it should be noted that new and different objective functions will be used for P2MP computation. Definitions for core objective functions can be found in [RFC5541] together with usage procedures. New objective functions for use with P2MP path computations will need to be defined and allocated codepoints in a separate document.
Section 3.1.1. Such legacy implementations will not be able to make use of the new reason code described in Section 3.1.3. R4: Therefore, at least one parameter required for inclusion in a P2MP Path Computation Request message MUST be defined in such a way as to cause automatic rejection as unprocessable or unrecognized by a back-level PCE implementation without requiring any changes to that PCE. It is RECOMMENDED that the parameter that causes this result be the parameter described in Section 3.1.1. RFC4875]. The Path Computation Response MUST be able to carry the P2MP path as either a compressed path (but not necessarily using the identical encoding as described in [RFC4875]), or as a non-compressed path comprising a series of source-to-leaf point-to-point (P2P) paths (known as S2L sub-paths). R7: By default, the path returned by the PCE SHOULD use the compressed format. The request from the PCC MAY allow the PCC to express a preference for receiving a compressed or non-compressed P2MP path in the response.
RFC4657] for reliable and in-order message delivery, so it is assumed that components of the sequence will be delivered in order and without missing components. RFC4875] requires that all branches of a single P2MP LSP have the same characteristics, and achieves this by not allowing the signaling parameters to be varied for different branches of the same P2MP LSP. R9: It MUST NOT be possible to set different constraints, traffic parameters, or quality-of-service requirements for different destinations of a P2MP LSP within a single computation request. RFC4657]. Note, however, that a consequence of this requirement is that it MUST be possible to supply an existing path in a Path Computation Request. This requirement is unchanged from [RFC4657], but it is a new requirement that such paths MUST be able to be P2MP paths. The PCC MUST be able to supply these paths as compressed paths or as non-compressed paths (see Section 3.1.6) according to the preference of the PCC. RFC4657]. To support this, the existing path MUST be supplied as described in Section 3.1.9. Because P2MP LSPs are more complex, it is often the case that small optimization improvements can be made after changes in network resource availability. However, re-signaling any LSP introduces risks to the stability of the service provided to the customer and the stability of the network, even when techniques like make-before-break [RFC3209] are used. Therefore, a P2MP Path Computation Request SHOULD contain a parameter that allows
the PCC to express a cost-benefit reoptimization threshold for the whole LSP, as well as per destination. The setting of this 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 supplied according to Section 3.1.6) have been modified from the paths supplied in the request. Section 3.1.9 is that 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 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 as a simple spur from the existing tree, or to recompute part of the P2MP tree. R12: To support this function for leaf additions, it MUST be possible to make the following indications in a Path Computation Request: - The path of an existing P2MP LSP (as described in Section 3.1.9). - Which destinations are new additions to the tree. - Which destinations of the existing tree must not have their paths modified. It MAY also be possible to indicate in a Path Computation Request a cost-benefit reoptimization threshold, such that the addition of new leaves will not cause reoptimization of the existing P2MP tree unless a certain improvement is made over simply grafting the new leaves to the existing tree. (Compare with Section 3.1.10.) 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 such a computation may yield optimizations over a simple pruning of the tree. The recomputation function in this case is 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 the entire P2MP TE LSP (that is, before the deletion of the destinations) in the Path Computation Request.
For both addition and deletion of destinations, the Path Computation Response SHOULD indicate which of the routes (as supplied according to Section 3.1.6) have been modified from the 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 local policy at the PCC and SHOULD be subject to policy at the PCE [RFC5394]. RFC4674], but may also be included in the PCECP message exchanges [RFC4657]. R14: The ability to perform P2MP path computation and the objective functions supported by a PCE SHOULD be advertised as part of PCE discovery. In the event that the PCE's ability to perform P2MP computation is not advertised as part of PCE discovery, the PCECP MUST allow a PCC to discover which PCEs with which it communicates support P2MP path computation, and which objective functions specific to P2MP path computation are supported by each PCE. The list of objective functions is assumed to be coordinated with those that can be requested as described in Section 3.1.2. These requirements do not represent a change to [RFC4657], except to add more capabilities and objective functions.
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 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. Section 3.1.13. Support for, and advertisement of support for, P2MP MPLS TE path computation MAY be subject to policy, and a PCE MAY hide its P2MP capabilities from certain PCCs by not advertising them through the discovery protocol and not reporting them to the specific PCCs in any PCECP capabilities exchange. Further, a PCE MAY be directed by policy to refuse a P2MP path computation for any reason including, but not limited to, the identity of the PCC that makes the request. RFC4657]. However, it should be noted that, in general, P2MP computations are likely to take longer than P2P computations. The liveness detection and monitoring features of the PCECP SHOULD take this into account.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008. [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, October 2009. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006. [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 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. [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009.