RFC 5376

Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)

📅 published November 2008, from ietf

Okay bestie, RFC 5376 is here and it's giving inter-AS PCE realness 💅✨

The header says this one came out of the Network Working Group in November 2008 🎀. It's an Informational doc, so it's sharing info with the Internet community, not setting a standard 🌸. The authors are N. Bitar (Verizon), R. Zhang (BT), and K. Kumaki (KDDI R&D Labs) 🫶. Its title is Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP). The header doesn't list anything it obsoletes or updates, so it's standing on its own 💜.

Status of This Memo ✨

Quick legal-ish stuff first. This memo gives info to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈.

Copyright (c) 2008 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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📜.

Abstract 🦋

Okay so MPLS Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) can live entirely inside one Autonomous System (AS), or they can cross AS boundaries. Main character energy, no cap 👑.

The Path Computation Element (PCE) is the component that's good at computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol (PCECP) is how PCEs talk to each other, and how Path Computation Clients (PCCs) talk to PCEs. PCECP is what asks for constrained paths and sends the computed ones back in response 💅. The general PCECP requirements live in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover using PCECP for inter-AS MPLS TE 🌸.

Table of Contents 🧚

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Reference Model .................................................4
      3.1. Scope of Deployment Model ..................................5
   4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path
      Computation .....................................................6
      4.1. PCE Communication Protocol Requirements ....................6
           4.1.1. Requirements for Path Computation Requests ..........6
           4.1.2. Requirements for Path Computation Responses .........7
      4.2. Scalability and Performance Considerations .................8
      4.3. Management Considerations ..................................8
      4.4. Confidentiality ............................................9
      4.5. Policy Controls Affecting Inter-AS PCECP ...................9
           4.5.1. Inter-AS PCE Peering Policy Controls ...............10
           4.5.2. Inter-AS PCE Re-Interpretation Policies ............10
   5. Security Considerations ........................................10
      5.1. Use and Distribution of Keys ..............................11
      5.2. Application of Policy .....................................11
      5.3. Confidentiality ...........................................12
      5.4. Falsification of Information ..............................12
   6. Acknowledgments ................................................12
   7. Normative References ...........................................13
   8. Informative References .........................................13

1. Introduction ✨

[RFC4216] lays out the scenarios that make people want inter-AS Multiprotocol Label Switching Traffic Engineering (MPLS TE), and it sets the requirements for inter-AS MPLS TE. That covers both when the ASes belong to one Service Provider (SP) and when they belong to different SPs 💖.

There are three signaling options for setting up an inter-AS TE Label Switched Path (LSP) 🎀:

       1) contiguous TE LSP as documented in [RFC5151];
       2) stitched inter-AS TE LSP discussed in [RFC5150];
       3) nested TE LSP as in [RFC4206].

[RFC5152] describes how inter-domain TE LSPs get computed. Network elements along the signaling paths work out the per-domain constrained path segments. But the mechanisms in [RFC5152] don't guarantee an optimum constrained path across multiple ASes. An optimum path for a TE LSP is the one with the smallest cost, based on a normalized TE metric (built from a TE metric or Interior Gateway Protocol (IGP) metric adopted in each transit AS), among all the paths that satisfy the LSP TE constraints 🔥.

The Path Computation Element (PCE) [RFC4655] is a component that can compute paths for MPLS TE and Generalized Multiprotocol Label Switching Protocol ((G)MPLS TE) LSPs. The need for PCEs came from SPs who wanted to compute optimum constrained paths across multiple areas and/or domains, and who wanted to split the path computation elements off from the forwarding elements 🧚.

PCECP is defined so PCCs and PCEs can communicate, and PCEs can communicate with each other. It's used to request (G)MPLS TE paths and to send computed paths back. The generic requirements for PCECP are covered in [RFC4657]. This document adds a set of PCECP requirements specific to inter-AS (G)MPLS TE path computation 💅.

2. Terminology 📖

This document uses the definitions and acronyms from Section 3 of [RFC4216] and Section 2 of [RFC4655]. We also use the following terms 🌸:

  • ASBR: Autonomous System Border Router (see section 3 of RFC 4216)
  • PCECP: PCE Communication Protocol
  • (G)MPLS TE: MPLS or Generalized MPLS Traffic Engineering
  • Inter-AS (G)MPLS TE path: An MPLS TE or Generalized MPLS (GMPLS) path that traverses two or more ASes.
  • Intra-AS (G)MPLS TE path: An MPLS TE or GMPLS path that is confined to a single AS. It may traverse one or more IGP areas.
  • Intra-AS PCE: A PCE responsible for computing (G)MPLS TE paths remaining within a single AS.
  • Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS paths or path segments, possibly by cooperating with intra-AS PCEs.

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

3. Reference Model 🗺️

Figure 1 shows the reference model for PCEs in an inter-AS setup. There are two kinds of PCE functions in this doc: inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs do the work needed for inter-AS (G)MPLS TE path computation, and intra-AS PCEs do the work needed for intra-AS (G)MPLS TE path computation 🦋.

              Inter-AS       Inter-AS              Inter-AS
        PCC <-->PCE1<--------->PCE2<---------------->PCE3
         ::      ::             ::                    ::
         ::      ::             ::                    ::
         R1----ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
         |       |        |            |        |           |
         |       |        |            |        |           |
         R2----ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
                                ::
                                ::
                             Intra-AS
                                PCE

         <==AS1==>        <=====AS2=====>       <====AS3====>

          Figure 1: Inter- and Intra-AS PCE Reference Model

Let's walk through a scenario with PCCs, inter-AS PCEs, and intra-AS PCEs, using Figure 1 🍓. R1 in AS1 wants to set up a (G)MPLS TE path, LSP1, with certain constraints to R7 in AS3. Using mechanisms outside the scope of this document, R1 figures out that R7 is an inter-AS route, and that R1 itself needs to contact its Inter-AS PCE1 to compute the path. As a PCC, R1 sends a PCECP path computation request to PCE1. PCE1 works out that R7 is reachable via AS2, and that PCE2 is the PCE to ask for path computation across AS2. So PCE1 sends a PCECP path computation request to PCE2 💖.

Inter-AS PCE2 then sends a PCECP path computation request to Intra-AS PCE R4 to compute a path within AS2. In certain cases, the same router, such as R3, can handle both inter-AS and intra-AS path computation functions. R4 might return a PCECP path computation response to PCE2 with ASBR3 as the entry point into AS2 from AS1, and ASBR7 as the exit point into AS3. PCE2 then sends a PCECP path computation request to PCE3 to compute the path segment across AS3, starting at ASBR7 and ending at R7. PCE3 returns a PCECP path computation response to PCE2 with the path segment ASBR7-R7. PCE2 then passes the path ASBR3-ASBR5-ASBR7-R7 back to PCE1, and PCE1 passes ASBR1-ASBR3-ASBR5-ASBR7-R7 back to PCC R1 🎀.

As the scenario shows, a PCC can generally contact an inter-AS PCE to request an inter-AS path. That PCE might supply the path itself, or it might call on other PCEs. Those can be inter-AS PCEs too, or they can be intra-AS PCEs that are only responsible for computing path segments within one AS 🫶.

This document describes the PCE Communication Protocol requirements for inter-AS path computation. That means PCCs sending path computation requests for inter-AS (G)MPLS TE paths to PCEs, and PCEs responding to them. It also covers the requirements for PCEs to communicate inter-AS path computation requests and responses between themselves 💜.

3.1. Scope of Deployment Model 🌈

Every attempt to predict future deployment scopes on the Internet has ended up fruitless 🙈. Still, it can help to talk through the scope of the inter-AS deployment model as it was envisioned when this was written.

It's expected that most, if not all, inter-AS PCECP communications will happen between PCEs working in the cooperative PCE model described in [RFC4655] ✨. In that model, the requesting PCE acts as a PCC when it issues a path computation request, but it also fills the wider role of a PCE in its own AS. It's currently considered unlikely that a PCC (for example, a normal Label Switching Router) will send a path computation request to a PCE outside its own AS. So the PCECP relationships between ASes are limited to at most n squared (n^2), where n is the number of peering PCEs in the various ASes (considered to be no greater than 100 in [RFC4657]) 🔥.

In practice, though, only a few PCEs in one AS will likely be picked for PCECP communications with a PCE in an adjacent AS. Each of those will only have a few PCEs in the adjacent AS to choose from. A deployment model might put PCEs co-resident with the ASBRs, which keeps the PCE-PCE relationships at a manageable scale 💅. Scaling considerations (Section 4.2), manageability considerations (Section 4.3), and security considerations (Section 5) should be examined in the light of these deployment expectations 🦋.

4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path Computation ✨

Okay bestie, this is where we get into the juicy details 🧚 This section covers the detailed PCECP requirements for inter-AS (G)MPLS TE LSPs. Depending on your deployment environment, some or all of these might be in play. Some are way more relevant to inter-provider inter-AS operations than to intra-provider ones, so don't panic if a few don't apply to you 💅

4.1. PCE Communication Protocol Requirements

Here's the lowdown on the requirements for inter-AS PCECP path computation requests and responses, split up into the sections below 🦋

4.1.1. Requirements for Path Computation Requests

These are the inter-AS specific requirements for PCECP requests for path computation, and they are giving main character energy 👑

  1. [RFC4657] states the requirement for a priority level to be associated with each path computation request. This document does not change that requirement. However, PCECP should include a mechanism that lets an inter-AS PCE tell the requesting inter-AS PCE about a change in the request priority level that may have resulted from a local policy being applied 🌸
  2. A path computation request by an inter-AS PCE or a PCC to another inter-AS PCE MUST be able to specify the sequence of ASes and/or ASBRs across the network by providing ASBRs and/or ASes as hops in the desired path of the TE LSP to the destination. For instance, an inter-AS PCE MUST be able to tell the inter-AS PCE serving the neighboring AS which preferred ASBR to use for exiting to that AS and reaching the destination. That is, where multiple ASBRs exist, the requester MUST be able to indicate a preference for one of them. The PCE must be able to indicate whether the specified ASBR or AS is mandatory or non-mandatory on the (G)MPLS TE path 🍓
  3. PCECP MUST allow a requester to provide a list of ASes and/or ASBRs to be excluded from the computed path. 🙈
  4. A PCECP path computation request from one inter-AS PCE to another MUST include the AS number of the requesting AS so the second inter-AS PCE can apply local policy correctly. 🔥
  5. A path computation request from a PCC to an inter-AS PCE, or from an inter-AS PCE to another, MUST be able to specify the need for protection against node, link, or Shared Risk Link Group (SRLG) failure using 1:1 detours or facility backup. It MUST be possible to request protection across all ASes or across specific ASes 🛡️
  6. PCECP MUST support the disjoint path requirements as specified in [RFC4657]. In addition, it MUST allow the specification of AS-diversity for the computation of a set of two or more paths 💜
  7. A PCECP path computation request message MUST be able to identify the scope of diversified path computation. That scope is either end-to-end (i.e., between the endpoints of the (G)MPLS TE tunnel) or limited to a specific AS 🦋

4.1.2. Requirements for Path Computation Responses

Now the responses, and this part is so iconic 💅 These are the inter-AS specific requirements for PCECP responses for path computation:

  1. A PCECP path computation response from one inter-AS PCE to another MUST be able to include both ASBRs and ASes in the computed path while preserving path segment and topology confidentiality 🤫
  2. A PCECP path computation response from one inter-AS PCE to the requesting inter-AS PCE MUST be able to carry an identifier for a path segment it computes, to preserve path segment and topology confidentiality. The point of the identifier is to be included in the TE LSP signaling (the mechanism for that is out of scope for this document), so it can be used for path expansion during LSP signaling ✨
  3. If a constraint for a desired ASBR (see Section 4.1.1, requirement 2) cannot be satisfied by a PCE, PCECP SHOULD allow the PCE to notify the requester of that fact as an error in a path computation response. ⚠️
  4. A PCECP path computation response from an inter-AS PCE to a requesting inter-AS PCE or a PCC MUST be able to carry a cumulative inter-AS path cost. Path cost normalization across ASes is out of scope for this document 🧮
  5. A PCECP path computation response from an inter-AS PCE to a PCC SHOULD be able to carry the intra-AS cost of the path segment within the PCC AS 🌈
  6. A PCECP path computation response MUST be able to identify diversified paths for the same (G)MPLS TE LSP. End-to-end (i.e., between the two endpoints of the (G)MPLS TE tunnel) disjoint paths are paths that do not share nodes, links, or SRLGs, except for the LSP head-end and tail-end. When diversified path segments are wanted within one or more ASes, the disjoint path segments may share only the ASBRs of the first AS and the ASBR of the last AS across those ASes. Bestie, that's a lot of diversity energy 😭

4.2. Scalability and Performance Considerations

PCECP design for use in the inter-AS case SHOULD consider the following criteria:

  • PCE message processing load.
  • Scalability as a function of the following parameters:
    • number of PCCs within the scope of an inter-AS PCE
    • number of intra-AS PCEs within the scope of an inter-AS PCE
    • number of peering inter-AS PCEs per inter-AS PCE
  • Added complexity caused by inter-AS features.

Basically, think about how much load this puts on PCEs and how well it scales 📈 It's giving planning ahead 🧠

4.3. Management Considerations

[RFC4657] specifies generic requirements for PCECP management. This document specifies new requirements that apply to inter-AS operations 🎀

The PCECP MIB module MUST provide objects to control the behavior of PCECP in inter-AS applications. These objects include the ASes within the scope of an inter-AS PCE, the inter-AS PCEs in neighboring ASes that the requesting PCE will or will not communicate with, confidentiality, and policies 🗂️

The built-in diagnostic tools MUST enable failure detection and status checking of PCC/PCE-PCE PCECP. Diagnostic tools include statistics collection on the historical behavior of PCECP as specified in [RFC4657], but additionally it MUST be possible to analyze these statistics on a neighboring AS basis (i.e., across the inter-AS PCEs that belong to a neighboring AS) 🔍

The MIB module MUST support trap functions when thresholds are crossed or when important events occur, as stated in [RFC4657]. These thresholds SHOULD be specifiable per neighbor AS as well as per peer inter-AS PCE, and traps should be generated accordingly 🚨

Basic liveliness detection for PCC/PCE-PCE PCECP is described in [RFC4657]. The PCECP MIB module SHOULD allow control of liveliness check behavior by providing a liveliness message frequency MIB object, and this frequency object SHOULD be specified per inter-AS PCE peer. In addition, there SHOULD be a MIB object that specifies the dead-interval as a multiplier of the liveliness message frequency, so that if no liveliness message is received within that time from an inter-AS PCE, that inter-AS PCE is declared unreachable 💀

4.4. Confidentiality

Confidentiality is a big deal here, so pay attention 🔐

Confidentiality mainly applies to inter-provider (inter-AS) PCE communication. It is about protecting the information exchanged between PCEs and protecting the topology information within an SP's network. Confidentiality rules may also apply among ASes owned by a single SP. In most cases, each SP designates some PCEs for inter-AS (G)MPLS TE path computation within its own administrative domain and some other PCEs for inter-provider inter-AS (G)MPLS TE path computation. Among the inter-provider-scoped inter-AS PCEs in each SP domain, there may also be a subset of PCEs specifically enabled for path computation across a specific set of ASes of different peer SPs 🫧

PCECP MUST allow an SP to hide from other SPs the set of hops within its own ASes that are traversed by an inter-AS inter-provider TE LSP (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative domain environment, SPs may want to hide their network topologies for security or commercial reasons. So, for each inter-AS TE LSP path segment an inter-AS PCE computes, it may return to the requesting inter-AS PCE an inter-AS TE LSP path segment from its own ASes without detailing the explicit intra-AS hops. As stated earlier, PCECP responses SHOULD be able to carry path-segment identifiers that replace the details of that path segment. Using that identifier for path expansion, for instance during LSP signaling, is out of scope for this document 🙊

4.5. Policy Controls Affecting Inter-AS PCECP

[RFC4216] Section 5.2.2 discusses the policy control requirements for inter-AS RSVP-TE signaling at AS boundaries, for enforcing interconnect agreements, attribute/parameter translation, and security hardening 🛠️

This section covers the policy control requirements that are similar to what [RFC4216] Section 5.2.2 discusses, but for PCECP. Please note that SPs may still require policy controls during signaling of TE LSPs to enforce their bilateral or multilateral agreements at AS boundaries, but signaling is out of scope for this document 📜

4.5.1. Inter-AS PCE Peering Policy Controls

An inter-AS PCE sends path computation requests to its neighboring inter-AS PCEs, and an inter-AS PCE that receives such a request enforces policies applicable to the sender of that request. These policies may include rewriting some of the parameters or rejecting requests based on parameter values. Such policies may be applied to PCEs belonging to different SPs, or to PCEs responsible for ASes within a single SP administrative domain. Parameters that might be subject to policy include bandwidth, setup/holding priority, Fast Reroute request, Differentiated Services Traffic Engineering (DS-TE) Class Type (CT), and others as specified in Section 5.2.2.1 of [RFC4216] 🧃

For path computation requests that do not comply with locally configured policies, PCECP SHOULD enable a PCE to send an error message to the requesting PCC or PCE, indicating that the request was rejected because a specific parameter did not satisfy local policy 🚫

4.5.2. Inter-AS PCE Re-Interpretation Policies

Each SP may define things differently in its use of, for example, DS-TE TE classes. An inter-AS PCE that receives a path computation request needs to interpret the parameters and constraints and adapt them to the local environment 🔄 Specifically, a request constructed by a PCC or PCE in one AS may have parameters and constraints that should be interpreted differently, or translated, by the receiving PCE in a different AS. A list of signaling parameters subject to policy re-interpretation at AS borders can be found in Section 5.2.2.2 of [RFC4216], and the list for path computation request parameters and constraints is the same. In addition, the transit SPs along the inter-AS TE path may be GMPLS transport providers, which may require re-interpretation of MPLS-specific PCECP path computation request objects in order to enable path computation over a GMPLS network, or vice versa 🌐

5. Security Considerations ✨

okay bestie, security is where things get dramatic 💀 The PCECP is a communications protocol that PCCs and PCEs use to talk to each other over an IP network, and those two can be far apart. So we have to protect the PCC, the PCE, and the info they swap. [RFC4758] lays out the PCECP requirements for guarding against spoofing, snooping, and DoS attacks 🛡️ That doc is about general protocol stuff for basic PCECP use. This one is all about the PCE architecture in an inter-AS environment, so it's only right to spotlight the security concerns that show up there 🔥

Security stuff that lives inside a single administrative domain becomes critical once you're in the multi-AS case. That's when control of IP traffic and network access can slip out of the hands of one administration 😭

5.1. Use and Distribution of Keys

How PCECP session participants find each other, and why they need a session at all, is out of scope for this document 🙈 It could happen through configuration or automatic discovery. But once a PCECP session is up, the PCECP speakers MUST have ways to authenticate each other's identities and validate the data they exchange 🔐 They SHOULD also have ways to protect that data with encryption 🫶 Those mechanisms usually need keys, so the PCECP MUST describe techniques for exchanging and using security keys 🗝️ If inter-AS PCE discovery is in use and PCECP security is required, automated key distribution mechanisms MUST also be used ✨ Key exchange has to happen across an AS boundary, so you need to think carefully about how inter-AS key exchanges get done and how the key exchange itself can be secured 💅 Key distribution mechanisms MUST be defined with [RFC4107] in mind 📚 And if a PCECP session is configured between a pair of inter-AS PCEs, a security key may be set manually for that session 🎀

5.2. Application of Policy

Policy is a big deal for how PCEs run in an inter-AS environment, as we covered in Section 4.5, especially when different SPs administer the ASes 👑 More on applying policy to the PCE architecture can be found in [PCE-POLICY] 📖

Policy can also be part of the security model for the PCECP, and it's especially useful for inter-AS path computation requests 💜 A key piece of applying policy at a PCE is knowing the identity of the requesting PCC/PCE, which is why the authentication from Section 5.1 matters so much 🙈 When policy info rides along in a computation request and/or response, the policy object is basically transparent to the PCECP. It gets delivered to the policy component of a PCE or PCC without being inspected or modified 🦋 So the policy components are on the hook for protecting that info (encrypting it, for example) and for adding extra identification and authentication if they need a higher level of validation than the base PCECP protocol elements give them 💀

5.3. Confidentiality

The PCECP MUST provide a mechanism to keep path segments computed by a PCE in one AS confidential when they're handed back in a computation response to another AS 🤫

Also, a PCE SHOULD get a mechanism to mask its identity, so that its presence in the path computation chain of a cooperative PCE model (like the one described in [BRPC]) can't be figured out from the computed path 🕵️‍♀️ This helps protect the PCE from targeted attacks 😭 Obviously, that confidentiality doesn't extend to the PCECP peer (a PCC or another PCE) that sends the PCE a path computation request, since that peer already knows it's talking to the PCE 🙃

5.4. Falsification of Information

In the PCE architecture, when PCEs team up, one PCE might return a path computation result made of several path segments, each computed by a different PCE 🧩 In the inter-AS case, every PCE could belong to a different administrative domain. The source PCC might not know about the downstream PCEs or fully trust them 🥺 Setting up a chain of trust between PCEs is possible and RECOMMENDED 🌈 But it might not always be doable, and then it becomes necessary to guard against a PCE changing info that a downstream PCE gave it 😱 So the PCECP MUST have some mechanism, echoed in the matching signaling, that lets an AS check that the signaled path matches the path segment computed by the local PCE and returned in the path computation request 🔍 This is serious stuff, periodt 💅

6. Acknowledgments

Huge thanks to Adrian Farrel, Jean-Philippe Vasseur, and Jean Louis Le Roux for their useful comments and suggestions 🫶 Pasi Eronen and Sandy Murphy gave valuable early Security Directorate reviews 🌸 And Adrian Farrel re-wrote the Security Considerations section 👑

7. Normative References

  • [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. 🔐
  • [RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 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. Informative References

  • [BRPC] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched paths", Work in Progress, April 2008. 🌊
  • [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 🍓
  • [RFC4758] Nystroem, M., "Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1", RFC 4758, November 2006. 🛡️
  • [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008. 🧵
  • [RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008. 🌸
  • [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008. 🎀
  • [PCE-POLICY] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", Work in Progress, October 2007. 📜

Authors' Addresses

Nabil Bitar
Verizon
117 West Street
Waltham, MA 02451 USA
EMail: nabil.n.bitar@verizon.com

Kenji Kumaki
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino
Saitama 356-8502, JAPAN
EMail: ke-kumaki@kddi.com

Raymond Zhang
BT
2160 E. Grand Ave.
El Segundo, CA 90245 USA
EMail: Raymond.zhang@bt.com
📦 where this page comes from