diff options
Diffstat (limited to 'doc/rfc/rfc4927.txt')
| -rw-r--r-- | doc/rfc/rfc4927.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc4927.txt b/doc/rfc/rfc4927.txt new file mode 100644 index 0000000..b606cea --- /dev/null +++ b/doc/rfc/rfc4927.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group J.-L. Le Roux, Ed. +Request for Comments: 4927 France Telecom +Category: Informational June 2007 + + + Path Computation Element Communication Protocol (PCECP) Specific + Requirements for Inter-Area MPLS and GMPLS Traffic Engineering + +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 + + Copyright (C) The IETF Trust (2007). + +Abstract + + For scalability purposes, a network may comprise multiple Interior + Gateway Protocol (IGP) areas. An inter-area Traffic Engineered Label + Switched Path (TE-LSP) is an LSP that transits through at least two + IGP areas. In a multi-area network, topology visibility remains + local to a given area, and a head-end Label Switching Router (LSR) + cannot compute an inter-area shortest constrained path. One key + application of the Path Computation Element (PCE)-based architecture + is the computation of inter-area TE-LSP paths. The PCE Communication + Protocol (PCECP) is used to communicate computation requests from + Path Computation Clients (PCCs) to PCEs, and to return computed paths + in responses. This document lists a detailed set of PCECP-specific + requirements for support of inter-area TE-LSP path computation. It + complements the generic requirements for a PCE Communication + Protocol. + + + + + + + + + + + + + + + + + +Le Roux Informational [Page 1] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + +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 + + [RFC4105] lists a set of motivations and requirements for setting up + TE-LSPs across IGP area boundaries. These LSPs are called inter-area + TE-LSPs. These requirements include the computation of inter-area + shortest constrained paths with a key guideline being to respect the + IGP hierarchy concept, and particularly the containment of topology + information. The main challenge with inter-area MPLS-TE lies in path + computation. Indeed, the head-end LSR cannot compute an explicit + path across areas, as its topology visibility is limited to its own + area. + + Inter-area path computation is one of the key applications of the + PCE-based architecture [RFC4655]. The computation of optimal inter- + area paths may be achieved using the services of one or more PCEs. + + Such PCE-based inter-area path computation could rely for instance on + a single multi-area PCE that has the TE database of all the areas in + the IGP domain and can directly compute an end-to-end constrained + shortest path. Alternatively, this could rely on the cooperation + between PCEs whereby each PCE covers one or more IGP areas and the + full set of PCEs covers all areas. + + + + +Le Roux Informational [Page 2] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + + The generic requirements for a PCE Communication Protocol (PCECP), + which allows a PCC to send path computation requests to a PCE and the + PCE to send path computation responses to a PCC, are set forth in + [RFC4657]. The use of a PCE-based approach for inter-area path + computation implies specific requirements on a PCE Communication + Protocol, in addition to the generic requirements already listed in + [RFC4657]. This document complements these 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, which is out of + the scope of this document. 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. + + + + + +Le Roux Informational [Page 3] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + + 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 + + IGP hierarchy enables improved IGP scalability by dividing 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 information about + reachability to destinations in other areas. Thus, a head-end LSR + cannot compute an end-to-end path that crosses the boundary of its + IGP area(s). + + A current solution for computing inter-area TE-LSP path relies on a + per-domain path computation [PD-COMP]. It is based on loose hop + routing with an ERO expansion on each ABR. This allows an LSP to be + set up following a constrained path, but faces 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, such a path is the + path that would have been computed by making use of some CSPF + algorithm in the absence of multiple IGP areas. + + The PCE-based architecture [RFC4655] is well suited to inter-area + path computation. It allows the path computation limitations + resulting from the limited topology visibility to be overcome by + introducing path computation entities with more topology visibility, + or by allowing cooperation between path computation entities in each + area. + + + + + + + + + +Le Roux Informational [Page 4] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + + There are two main approaches for the computation of 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 the use of a PCE-based approach to perform inter-area path + computation implies specific functional requirements in a PCECP, in + addition to the generic requirements listed in [RFC4657]. These + 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 + that complement requirements listed in [RFC4657] and are specific to + inter-area (G)MPLS-TE path computation. + +4.1. Control and Recording of Area Crossing + + In addition to the path constraints specified in [RFC4657], the + request message MUST allow indicating whether or not area crossing is + permitted. Indeed, 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, as far as possible, + crossing areas and thus may prefer selecting 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. + + + + + + + + + + +Le Roux Informational [Page 5] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + +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. + +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 if 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 + + In case of multiple-PCE inter-area path computation, a PCC may want + to indicate a preferred list of PCEs to be used, one per area. In + each area, the preferred PCE should be tried before another PCE is + selected. Note that if there is no preferred PCE indicated for an + area, any PCE in that area may be used. + + Hence, the PCECP request message MUST support the inclusion of a list + of preferred PCEs per area. Note that this requires that a PCC in + one area has knowledge of PCEs in other areas. This could rely on + configuration or on a PCE discovery mechanism, allowing discovery + across area boundaries (see [RFC4674]). + + Also, it would be useful to know the list of PCEs that effectively + participated in the computation. Hence, the request message MUST + support a request for PCE recording, and the response message MUST + support the recording of the set of one or more PCEs that took part + in the computation. + + It may also be useful to know the path segments computed by each PCE. + Hence, the request message SHOULD allow a request for the + identification of path segments computed by a PCE, and the response + message SHOULD allow identifying the path segments computed by each + PCE. + + + + + + + +Le Roux Informational [Page 6] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + +4.5. Inclusion of Area IDs in Request + + Knowledge of the areas in which the source and destination lie would + allow a PCE to select an appropriate downstream PCE. This would be + useful when the area ID(s) of a PCE (i.e., the area(s) where it has + visibility) is/are known, which can be achieved by the PCE Discovery + Protocol (see [RFC4674]) or by any other means. + + A PCE may not have any visibility of the source/destination area and + hence may not be able to determine the area of the + source/destination. In such a situation, it would be useful for a + PCC to indicate the source and destination area IDs in its request + message. + + For that purpose, the request message MUST support the inclusion of + the source and destination area IDs. Note that this information + could be learned by the PCC through configuration. + +4.6. Area Inclusion/Exclusion + + In some situations, it may be useful for the request message to + indicate one or more area(s) that must be followed by the path to be + computed. It may also be useful for the request message to indicate + one or more area(s) that must be avoided by the path to be computed + (e.g., request for a path between LSRs in two stub areas connected to + the same ABR(s), which must not cross the backbone area). Hence, 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 various reasons, including protection and load balancing, the + computation of diverse inter-area paths may be required. There are + various 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 may share ABRs, in which case path segments within + an area are node-disjoint, but end-to-end paths are not node + disjoint. + + + + +Le Roux Informational [Page 7] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + + 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, in order to ensure SRLG consistency, SRLG identifiers + within the IGP domain should be assigned and allocated by the same + entity. + + Note that 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 + + In addition to the policy requirements discussed in [RFC4657], the + application of inter-area path computation policies requires some + additional information to be carried in the PCECP request messages. + The request message MUST allow for the inclusion of the address of + the originating PCC. This may be useful in a multiple-PCE + computation, so as to apply policies not only 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 being undertaken as a separate work item + in the PCE working group [PCE-POL-FMWK]. + +4.9. Loop Avoidance + + In case of multiple-PCE inter-area path computation, there may be + risks of PCECP request loops. A mechanism MUST be defined to detect + and correct PCECP request message loops. This may rely, for + instance, on the recording, in the request message, of the set of + traversed PCEs. + + Also, the returned path in a response message MUST be loop free. + + + + + + + +Le Roux Informational [Page 8] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + +5. Manageability Considerations + + The inter-area application implies some new manageability + requirements in addition to those 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 performances of a + PCE chain (minimum, maximum, and average response times), in case of + multiple-PCE inter-area path computation. + + It is really important, for diagnostic and troubleshooting reasons, + to monitor the availability and performances of each PCE of a PCE + chain used for inter-area path computation. Particularly, it is + really important to identify the PCE(s) responsible for a delayed + reply. + + Hence, a mechanism MUST be defined to monitor the performances 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 + + 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]. + +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. + + + + + + +Le Roux Informational [Page 9] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + + [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 + + + + + + + + + +Le Roux Informational [Page 10] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + + 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 + + + + + + + +Le Roux Informational [Page 11] + +RFC 4927 PCECP Requirements for MPLS and GMPLS June 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Le Roux Informational [Page 12] + |