RFC 4927

Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering

📅 published June 2007, from ietf

Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering ✨

okay bestie, this is RFC 4927 🎀 It's an Informational doc from the Network Working Group, edited by J.-L. Le Roux of France Telecom, and it came out in June 2007. Informational means it's sharing knowledge with the Internet community and does not specify an Internet standard 💅 The header doesn't list anything it obsoletes or updates, so there's no drama there 🧚

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 📜

Copyright Notice 🌸

Abstract 💜

okay so a network can have a bunch of Interior Gateway Protocol (IGP) areas to stay scalable 🦋 An inter-area Traffic Engineered Label Switched Path (TE-LSP) is an LSP that goes through at least two IGP areas. The thing is, in a multi-area network the topology visibility stays local to one area, so a head-end Label Switching Router (LSR) can't compute an inter-area shortest constrained path on its own 😭 One key application of the Path Computation Element (PCE)-based architecture is computing inter-area TE-LSP paths, and that's where the PCE Communication Protocol (PCECP) comes in. It carries computation requests from Path Computation Clients (PCCs) to PCEs, and sends the computed paths back in responses. This document lists a detailed set of PCECP-specific requirements for inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol. 🔥

Table of Contents 🧚

1. Introduction ....................................................2
2. Terminology .....................................................3
   2.1. Conventions Used in This Document ..........................4
3. Motivations for PCE-Based Inter-Area Path Computation ...........4
4. Detailed Inter-Area Specific Requirements on PCECP ..............5
   4.1. Control and Recording of Area Crossing .....................5
   4.2. Area Recording .............................................6
   4.3. Strict Explicit Path and Loose Path ........................6
   4.4. PCE List Enforcement and Recording in Multiple-PCE
        Computation ................................................6
   4.5. Inclusion of Area IDs in Request ...........................7
   4.6. Area Inclusion/Exclusion ...................................7
   4.7. Inter-Area Diverse Path Computation ........................7
   4.8. Inter-Area Policies ........................................8
   4.9. Loop Avoidance .............................................8
5. Manageability Considerations ....................................9
6. Security Considerations .........................................9
7. Acknowledgments .................................................9
8. References ......................................................9
   8.1. Normative References .......................................9
   8.2. Informative References ....................................10
9. Contributors ...................................................10

1. Introduction ✨

okay so [RFC4105] is the one that lists the motivations and requirements for setting up TE-LSPs across IGP area boundaries 🗺️ These LSPs are called inter-area TE-LSPs. The requirements include computing inter-area shortest constrained paths, and the big guideline is to respect the IGP hierarchy concept, especially keeping topology information contained. The main challenge with inter-area MPLS-TE is path computation, because the head-end LSR can't compute an explicit path across areas. Its topology visibility is limited to its own area, so it's kinda stuck 🙈

Inter-area path computation is one of the key applications of the PCE-based architecture [RFC4655] 💖 Optimal inter-area paths may be achieved using the services of one or more PCEs.

Such PCE-based inter-area path computation could rely on, for instance, a single multi-area PCE. That PCE has the TE database of all the areas in the IGP domain and can directly compute an end-to-end constrained shortest path, which is giving main character energy 👑 Alternatively, it could rely on cooperation between PCEs, where each PCE covers one or more IGP areas and the full set of PCEs covers all areas.

The generic requirements for a PCE Communication Protocol (PCECP) are set forth in [RFC4657] 📝 That protocol lets a PCC send path computation requests to a PCE, and lets the PCE send path computation responses to a PCC. Using a PCE-based approach for inter-area path computation implies specific requirements on a PCE Communication Protocol, on top of the generic ones already listed in [RFC4657]. This document complements those generic requirements by listing a detailed set of PCECP requirements specific to inter-area path computation 🫶

It is expected that PCECP procedures be defined to satisfy these requirements. 🎀

Note that PCE-based inter-area path computation may require a mechanism for automatic PCE discovery across areas. That's out of the scope of this document, but detailed requirements for such a mechanism are discussed in [RFC4674] 🦋

2. Terminology 📖

LSR: Label Switching Router.

LSP: MPLS Label Switched Path.

TE-LSP: Traffic Engineered Label Switched Path.

IGP area: OSPF area or IS-IS level.

ABR: IGP Area Border Router, a router that is attached to more than one IGP area (ABR in OSPF or L1/L2 router in IS-IS).

Inter-Area TE-LSP: TE-LSP that traverses more than one IGP area.

CSPF: Constrained Shortest Path First.

SRLG: Shared Risk Link Group.

PCE: Path Computation Element: an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.

PCC: Path Computation Client, any application that request path computation to be performed by a PCE.

PCECP: PCE Communication Protocol, a protocol for communication between PCCs and PCEs, and between PCEs.

ERO: Resource Reservation Protocol (RSVP)-TE Explicit Route Object. It encodes the explicit path followed by a TE-LSP.

2.1. 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 [RFC2119]. 🌈

3. Motivations for PCE-Based Inter-Area Path Computation 🔥

okay so IGP hierarchy makes IGP scale better by splitting the IGP domain into areas and limiting the flooding scope of topology information to within area boundaries 🧠 A router in an area has full topology information for its own area, but only reachability info for destinations in other areas. So a head-end LSR can't compute an end-to-end path that crosses the boundary of its IGP area(s). Literally the whole problem in one sentence 😭

A current solution for computing an inter-area TE-LSP path relies on a per-domain path computation [PD-COMP]. It's based on loose hop routing with an ERO expansion on each ABR. This lets an LSP be set up following a constrained path, but it has two major limitations:

This does guarantee the use of an optimal constrained path.
This may lead to several crankback signaling messages and hence delay the LSP setup, and may also invoke possible alternate routing activities.

Note that, here, by optimal constrained path we mean the shortest constrained path across multiple areas, taking into account either the IGP or TE metric [RFC3785]. In other words, it's the path that would have been computed by using some CSPF algorithm in the absence of multiple IGP areas ✨

The PCE-based architecture [RFC4655] is well suited to inter-area path computation 🦋 It overcomes the path computation limits caused by limited topology visibility, either by introducing path computation entities with more topology visibility, or by letting path computation entities in each area cooperate.

There are two main approaches for computing an inter-area optimal path 🎀

Single-PCE computation: The path is computed by a single PCE that has topology visibility in all areas and can compute an end-to-end optimal constrained path on its own.
Multiple-PCE computation with inter-PCE communication: The path computation is distributed on multiple PCEs, which have partial topology visibility. They compute path segments in their domains of visibility and collaborate with each other so as to arrive at an end-to-end optimal constrained path. Such collaboration is ensured thanks to inter-PCE communication.

Note that using a PCE-based approach to perform inter-area path computation implies specific functional requirements in a PCECP, on top of the generic requirements listed in [RFC4657]. Those specific requirements are discussed in the next section 💖

4. Detailed Inter-Area Specific Requirements on PCECP 🫧

This section lists a set of additional requirements for the PCECP. They complement the requirements listed in [RFC4657] and are specific to inter-area (G)MPLS-TE path computation 🍓

4.1. Control and Recording of Area Crossing 🌸

On top of the path constraints specified in [RFC4657], the request message MUST allow indicating whether or not area crossing is permitted. Here's the deal: when the source and destination reside in the same IGP area, there may be intra-area and inter-area feasible paths. As set forth in [RFC4105], if the shortest path is an inter-area path, an operator either may want to avoid crossing areas as far as possible, and may therefore prefer a sub-optimal intra-area path, or, conversely, may prefer to use a shortest path even if it crosses areas 🙈

Also, when the source and destination reside in the same area, it may be useful to know whether the returned path is an inter-area path. Hence, the response message MUST allow indicating whether the computed path is crossing areas. 🫶

4.2. Area Recording 🗺️

It may be useful for the PCC to know the set of areas crossed by an inter-area path and the corresponding path segments 👀 Hence, the response message MUST allow identifying the crossed areas. Also, the response message MUST allow segmenting the returned path and marking each segment so that it is possible to tell which piece of the path lies within which area. Main character behavior, honestly 👑

4.3. Strict Explicit Path and Loose Path 💅

A Strict Explicit Path is defined as a set of strict hops, while a Loose Path is defined as a set of at least one loose hop and zero, one or more strict hops 🧚 An inter-area path may be strictly explicit or loose (e.g., a list of ABRs as loose hops). It may be useful to indicate to the PCE whether a Strict Explicit Path is required or not. Hence, the PCECP request message MUST allow indicating whether a Strict Explicit Path is required/desired. ✨

4.4. PCE List Enforcement and Recording in Multiple-PCE Computation 🎀

okay so in multiple-PCE inter-area path computation, a PCC can totally say "hey, here's my fave list of PCEs, one per area" 💖. In each area, the preferred PCE gets tried before anyone else is picked. ngl that's main character energy ✨. And if there's no preferred PCE listed for an area? Then any PCE in that area is fair game 🦋.

So the PCECP request message MUST support including a list of preferred PCEs per area. This means a PCC in one area needs to know about PCEs in other areas 👀. That could come from configuration, or from a PCE discovery mechanism that works across area boundaries (see [RFC4674]).

It's also super useful to know which PCEs actually joined the computation 🧚. So the request message MUST support asking for PCE recording, and the response message MUST support recording the set of one or more PCEs that took part in the computation.

It might be nice to know which path segments each PCE computed too 💅. So the request message SHOULD allow requesting identification of path segments computed by a PCE, and the response message SHOULD allow identifying the path segments computed by each PCE.

4.5. Inclusion of Area IDs in Request 🌸

Knowing the areas where the source and destination live lets a PCE pick an appropriate downstream PCE, periodt 💀. This is especially helpful when the area ID(s) of a PCE (i.e., the area(s) where it has visibility) are known, which can come from the PCE Discovery Protocol (see [RFC4674]) or any other means.

A PCE might not see the source or destination area at all, so it can't figure out which area they're in 😭. In that case, it's really helpful for the PCC to put the source and destination area IDs in its request message.

So the request message MUST support including the source and destination area IDs. The PCC could learn this through configuration, fr 🫶.

4.6. Area Inclusion/Exclusion 🦋

Sometimes the request message should say which area(s) the path must go through, and which area(s) it must avoid 🙈. Like, a path between LSRs in two stub areas connected to the same ABR(s), which must not cross the backbone area, is a classic example.

So the request message MUST allow indicating a set of one or more area(s) that must be explicitly included in the path, and a set of one or more area(s) that must be explicitly excluded from the path.

4.7. Inter-Area Diverse Path Computation 👑

For reasons like protection and load balancing, computing diverse inter-area paths might be needed 💪. There are a few levels of diversity in an inter-area context:

Per-area diversity (intra-area path segments are link, node, or SRLG disjoint)
Inter-area diversity (end-to-end inter-area paths are link, node, or SRLG disjoint)

Note that two paths may be disjoint in the backbone area but non-disjoint in peripheral areas. Also, two paths may be node disjoint within areas but share ABRs. In that case, path segments within an area are node disjoint, but end-to-end paths are not node disjoint 😵‍💫.

The request message MUST allow requesting the computation of a set of inter-area diverse paths between the same node pair or between distinct node pairs. It MUST allow indicating the required level of diversity of a set of inter-area paths (link, node, and SRLG diversity), as well as the required level of diversity of a set of intra-area segments of inter-area paths (link, node, and SRLG diversity) on a per-area basis.

The response message MUST allow indicating the level of diversity of a set of computed inter-area loose paths (link, node, and SRLG diversity), globally, and on a per-area basis (link, node, and SRLG diversity of intra-area path segments).

Note that, to keep SRLG consistency, SRLG identifiers within the IGP domain should be assigned and allocated by the same entity 🧠.

Also, specific objective functions may be requested for diverse path computation, such as minimizing the cumulated cost of a set of diverse paths as set forth in [RFC4657] 💜.

4.8. Inter-Area Policies 🔥

On top of the policy requirements in [RFC4657], inter-area path computation policies need some extra info carried in the PCECP request messages. The request message MUST allow for the inclusion of the address of the originating PCC. This is handy in a multiple-PCE computation, because it lets policies apply not just based on the PCECP peer but also based on the originating PCC 🙌.

Note that work on supported policy models and the corresponding requirements/implications is happening as a separate work item in the PCE working group [PCE-POL-FMWK] 📋.

4.9. Loop Avoidance 🔁

In multiple-PCE inter-area path computation, there can be a risk of PCECP request loops 😱. A mechanism MUST be defined to detect and correct PCECP request message loops. This may rely, for instance, on recording in the request message the set of traversed PCEs.

Also, the returned path in a response message MUST be loop free 💅.

5. Manageability Considerations 🛠️

The inter-area application brings some new manageability requirements on top of the ones already listed in [RFC4657]. The PCECP PCC and PCE MIB modules MUST allow recording the proportion of inter-area requests and the success rate of inter-area requests. The PCECP PCC MIB module MUST also allow recording the performance of a PCE chain (minimum, maximum, and average response times) in the case of multiple-PCE inter-area path computation 📊.

For diagnostics and troubleshooting, it is seriously important to monitor the availability and performance of each PCE in a PCE chain used for inter-area path computation 🫠. Especially, it's crucial to identify the PCE(s) responsible for a delayed reply.

So a mechanism MUST be defined to monitor the performance of a PCE chain. It MUST allow determining the availability of each PCE of the chain, as well as its minimum, maximum, and average response times 🔍.

6. Security Considerations 🔐

Okay, serious moment bestie 🚨: IGP areas are administrated by the same entity. Hence, the inter-area application does not imply a new trust model or new security issues beyond those already defined in [RFC4657]. Read that again, we're not inventing new security problems here 🛡️.

7. Acknowledgments 💌

We would also like to thank Adrian Farrel, Jean-Philippe Vasseur, Bruno Decraene, Yannick Le Louedec, Dimitri Papadimitriou, and Lou Berger for their useful comments and suggestions 🌷. Thanks also to Ross Callon, Catherine Meadow, and Dan Romascanu for their review during the final stages of publication 🥹.

8. References 📚

8.1. Normative References

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4105]      Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J.
               Boyle, Ed., "Requirements for Inter-Area MPLS Traffic
               Engineering", RFC 4105, June 2005.

[RFC4655]      Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
               Computation Element (PCE)-Based Architecture", RFC
               4655, August 2006.

[RFC4657]      Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
               Element (PCE) Communication Protocol Generic
               Requirements", RFC 4657, September 2006.

8.2. Informative References

[RFC4674]      Le Roux, J., Ed., "Requirements for Path Computation
               Element (PCE) Discovery", RFC 4674, October 2006.

[PD-COMP]      Vasseur, J.P., Ed., Ayyangar, A., Ed., and R. Zhang,
               "A Per-domain path computation method for computing
               Inter-domain Traffic Engineering (TE) Label Switched
               Path (LSP)", Work in Progress, April 2007.

[PCE-POL-FMWK] Bryskin, I., Papadimitriou, D., Berger L., and J.
               Ash, "Policy-Enabled Path Computation Framework", Work
               in Progress, March 2007.

[RFC3785]      Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P.,
               and T. Telkamp, "Use of Interior Gateway Protocol
               (IGP) Metric as a second MPLS Traffic Engineering (TE)
               Metric", BCP 87, RFC 3785, May 2004.

9. Contributors 🌈

Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
EMail: gash5107@yahoo.com

Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
EMail: nabil.n.bitar@verizon.com

Dean Cheng
Cisco Systems Inc.
3700 Cisco Way
San Jose, CA 95134 USA
Phone: +1 408 527 0677
EMail: dcheng@cisco.com

Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103
EMail: ke-kumaki@kddi.com

Eiji Oki
NTT
Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585, JAPAN
EMail: oki.eiji@lab.ntt.co.jp

Raymond Zhang
BT
2160 E. Grand Ave.
El Segundo, CA 90245
USA
EMail: raymond.zhang@bt.com

Renhai Zhang
Huawei Technologies
No. 3 Xinxi Road, Shangdi,
Haidian District,
Beijing City,
P. R. China
EMail: zhangrenhai@huawei.com

Editor's Address 🖊️

Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
EMail: jeanlouis.leroux@orange-ftgroup.com

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧾

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Okay bestie, this one's short but it matters 💅 The RFC Editor function is currently funded by the Internet Society 🌸 That's the whole shout-out, and it's giving humble-but-essential energy ✨

📦 where this page comes from

ietf: rfc4927 2007-06
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms