RFC 5862

Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE 🦋

Request for Comments: 5862

Category: Informational 💅

ISSN: 2070-1721

Authors: S. Yasukawa (NTT Corporation) and A. Farrel (Old Dog Consulting)

Date: June 2010 🌸

Obsoletes and updates: the title block doesn't list anything it obsoletes or updates, so this one stands on its own 🫶

Abstract ✨

okay so the Path Computation Element (PCE) is the part of the network that does path computation to support traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 🧚

Point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs) got their own extensions to the MPLS and GMPLS signaling and routing protocols. PCE is already established in MPLS networks, and P2MP TE LSP routes can be seriously complicated to compute, so it's pretty likely PCE will end up doing the work for P2MP LSPs too. 💖

Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document adds to those generic requirements and lays out 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's published for informational purposes. 📚

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community and has had public review. It's been approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that. 🫠

Information about the current status of this document, any errata, and how to give feedback on it can be found 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 read these carefully, because they spell out 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 they come without warranty as described in the Simplified BSD License. 🙈

1. Introduction 🦋

The Path Computation Element (PCE) defined in [RFC4655] is an entity that can compute a network path or route based on a network graph and apply computational constraints. The idea is that PCE computes the path of Traffic Engineered Label Switched Paths (TE LSPs) inside 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 to support various features, including layer 3 multicast virtual private networks [RFC4834]. 🌸

Path computation for P2MP TE LSPs is a big challenge, and optimizing a network with multiple P2MP TE LSPs needs serious computing power. PCE gives you a way to offload those 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 in this document to justify using PCE for P2MP MPLS TE. 💅

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]. 🎀

2. Conventions Used in This Document 📚

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]. Even though this document isn't a protocol specification, this convention is adopted to keep the requirements clear. 🫶

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 for the computation of paths for P2MP LSPs. ✨

This requires no additional messages, but it does require adding the parameters described in the following sections to the existing PCC-PCE communication protocol messages. 🎀

3.1.1. Indication of P2MP Path Computation Request 🦋

R1: Although the presence of certain parameters (such as a list of more than one destination) MAY be used by a protocol specification to let an implementation infer that a Path Computation Request is for a P2MP LSP, an explicit parameter SHOULD be placed in a conspicuous place within a Path Computation Request message so a receiving PCE can easily tell that the request is for a P2MP path. 👑

3.1.2. Indication of P2MP Objective Functions 💜

R2: [RFC4657] includes the requirement to be able to specify the objective functions a PCE applies 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. 🌸

3.1.3. Non-Support of 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 Computation Request message with a reason code that indicates no support for P2MP path computation. 💀

3.1.4. Non-Support by Back-Level PCE Implementations 🍓

It's possible that initial PCE implementations will be developed without support for P2MP path computation and without the ability to recognize the explicit parameter described in Section 3.1.1. Legacy implementations like that won't be able to use 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 that a back-level PCE implementation automatically rejects it as unprocessable or unrecognized, without needing any changes to that PCE. It is RECOMMENDED that the parameter causing this result be the parameter described in Section 3.1.1. 🔥

3.1.5. Specification of Destinations 🌈

R5: Since P2MP LSPs have more than one destination, it MUST be possible for a single Path Computation Request to list multiple destinations. 🫶

3.1.6. Indication of P2MP Paths 🦋

R6: The Path Computation Response MUST be able to carry the path of a P2MP LSP. ✨

P2MP paths can be expressed as a compressed series of routes, as described in [RFC4875]. The Path Computation Response MUST be able to carry the P2MP path either as a compressed path (though not necessarily using the identical encoding described in [RFC4875]), or as a non-compressed path made up of 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 let the PCC express a preference for receiving a compressed or non-compressed P2MP path in the response. 💖

3.1.7. Multi-Message Requests and Responses 🧚

R8: A single P2MP LSP may have many destinations, and the computed path (tree) may be very extensive. In these cases, the entire Path Computation Request or Response may not fit within one PCE message. Therefore, it MUST be possible for a single request or response to be conveyed by a sequence of PCE messages. 😭

Note that [RFC4657] has a requirement for reliable and in-order message delivery, so it is assumed that the components of the sequence will be delivered in order and without missing components. 🫶

3.1.8. Non-Specification of Per-Destination Constraints and Parameters 💜

[RFC4875] requires that all branches of a single P2MP LSP have the same characteristics, and it achieves this by not allowing the signaling parameters to vary across 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. 🙈

3.1.9. Path Modification and Path Diversity 🌈

R10: No changes are made to the requirement to support path modification and path diversity as described in [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. 👑

3.1.10. Reoptimization of P2MP TE LSPs ✨

R11: Reoptimization MUST be supported for P2MP TE LSPs as described for P2P LSPs in [RFC4657]. To support this, the existing path MUST be supplied as described in Section 3.1.9. 🎀

Because P2MP LSPs are more complex, small optimization improvements can often 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 lets the PCC 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. 🫶

3.1.11. Addition and Removal of Destinations from Existing Paths ✨

okay so a variation of the path modification from Section 3.1.9 is that destinations can be added to, or removed from, existing P2MP TE LSPs 🌸

when you add destinations, you need to compute a path for a brand-new branch of the P2MP LSP 🌿. You can recompute the whole P2MP tree, bolt the new branch on as a simple spur off the existing tree, or recompute just part of the tree. It's giving options 💅

R12: to support this 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 a cost-benefit reoptimization threshold in a Path Computation Request. With that, adding new leaves won't cause reoptimization of the existing P2MP tree unless the improvement is big enough to beat simply grafting the new leaves onto the existing tree 🦋 (compare with Section 3.1.10).

When you delete destinations, you don't have to compute a new path for the P2MP TE LSP. Still, a computation might find optimizations that a plain prune wouldn't 🧚 The recomputation here is basically the same as the one in Section 3.1.10, but it MAY be possible to supply the full previous path of the entire P2MP TE LSP (that is, from before the destinations were deleted) in the Path Computation Request 💜

For both adding and deleting 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]. Policy is the main character here, bestie 👑

3.1.12. Specification of Applicable Branch Nodes

okay so for administrative, security or other policy reasons, you might want to limit which nodes in the network can be used as branch points for a given LSP 🍓 That means giving the path computation either a limiting set of nodes that can be used as branches, or a list of nodes that must not be used as branch points 🔥

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 nodes for a P2MP path computation. 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 path computation 🌈

3.1.13. Capabilities Exchange

PCE capabilities exchange is part of PCE discovery [RFC4674], but it may also be included in the PCECP message exchanges [RFC4657] 🫶

R14: the ability to perform P2MP path computation and the objective functions a PCE supports SHOULD be advertised as part of PCE discovery 💖 If 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 it communicates with support P2MP path computation, and which P2MP-specific objective functions each PCE supports 🔍

The list of objective functions is assumed to be coordinated with the ones that can be requested as described in Section 3.1.2 🎀

These requirements don't change [RFC4657], except that they add more capabilities and objective functions 🌸

3.1.14. Path-Tree Diversity

Section 3.1.9 sets out the requirement to be able to request multiple diverse paths. On top of that, with P2MP trees, it may be that only parts of the tree can be diverse, or that only parts need to be 🦋

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 ✨

---

4. Manageability Considerations 🧚

4.1. Control of Function and Policy

PCE implementations MAY provide a configuration switch so that support of P2MP MPLS TE computations can be enabled or disabled 💅 When the level of support changes, this SHOULD be re-advertised as described in Section 3.1.13 🔥

Support for, and advertisement of support for, P2MP MPLS TE path computation MAY be subject to policy 🌈 A PCE MAY hide its P2MP capabilities from certain PCCs by not advertising them through the discovery protocol and not reporting them to those 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 making the request 👑

4.2. Information and Data Models

PCECP protocol extensions for P2MP MPLS TE SHOULD be accompanied by MIB objects for controlling and monitoring the protocol and the PCE that does the computations 💜 The MIB objects MAY be provided in the same MIB module used for general PCECP control and monitoring, or MAY be provided in a new MIB module 🍓

The MIB objects SHOULD provide the ability to control and monitor all aspects of PCECP relevant to P2MP MPLS TE path computation 🦋

4.3. Liveness Detection and Monitoring

No changes are necessary to the liveness detection and monitoring requirements already embodied in [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 💖

4.4. Verifying Correct Operation

There are no additional requirements beyond those in [RFC4657] for verifying the correct operation of the PCECP ✨ Verifying the correct operation of the PCE and its algorithms is out of scope for the protocol requirements, but a PCC MAY send the same request to more than one PCE and compare the results 🔍

4.5. Requirements on Other Protocols and Functional Components

A PCE operates on a topology graph that may be built from information distributed by TE extensions to the routing protocol running in the network 🌿 For the PCE to pick a suitable path for the signaling protocol to use when installing the P2MP LSP, the topology graph must include information about the P2MP signaling and branching capabilities of each LSR in the network 🧠

Whatever means is used to collect the information for building the topology graph, the graph MUST include the requisite information 💅 If the TE extensions to the routing protocol are used, these SHOULD be as described in [RFC5073] 🎀

4.6. Impact on Network Operation

Using a PCE to compute P2MP paths isn't expected to have a significant impact on network operations 🌈 It should be noted, though, that adding P2MP support to a PCE that already provides P2P path computation might change the PCE's load significantly 😭 That could affect network behavior, especially during the recovery periods right after a network failure 💀

5. Security Considerations 🔐

P2MP computation requests don't raise any additional security issues for the PCECP, because no new messages and no new PCC-PCE relationships or transactions are introduced ✨

🚨 Be warned, bestie: P2MP computation requests are more CPU-intensive and also use more link bandwidth. So if the PCECP was susceptible to denial of service attacks based on the injection of spurious Path Computation Requests, supporting P2MP path computation would make that effect worse 💀

It would be possible to consider applying different authorization policies to P2MP Path Computation Requests compared with other requests 🔥

6. Acknowledgments 🫶

Thanks to Dean Cheng, Young Lee, Quintin Zhao, Daniel King, Fabien Verhaeghe, and Francis Dupont for their comments and suggestions on this document 💖

7. References 📚

7.1. Normative References

• [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.

7.2. Informative References

• [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.

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