Network Working Group J.-L. LeRoux (Editor) Internet DraftRoux, Ed. Request for Comments: 4927 France Telecom Category: InformationalExpires:June 2007December 2006 PCEPath Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-AreaMulti Protocol Label Switching (MPLS) and GeneralizedMPLS(GMPLS)and GMPLS Traffic Engineeringdraft-ietf-pce-pcecp-interarea-reqs-05.txtStatus ofthisThis MemoBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents ofThis memo provides information for the InternetEngineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximumcommunity. It does not specify an Internet standard ofsix months and may be updated, replaced, or obsoleted by other documents atanytime. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The listkind. Distribution ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.this memo is unlimited. Copyright Notice Copyright (C) Thelist of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.IETF Trust (2007). Abstract For scalabilitypurposespurposes, a network may comprise multiple Interior Gateway Protocol (IGP) areas. An inter-area TrafficEngineered-LabelEngineered 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(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(PCC)(PCCs) to PCEs, and to return computed paths in responses. This document lists a detailed set ofPCECP specificPCECP-specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol.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.Table of Contents 1.Terminology.................................................3Introduction ....................................................3 2.Introduction................................................3Terminology .....................................................3 2.1. Conventions Used in This Document ..........................4 3. Motivations forPCE-basedPCE-Based Inter-Area PathComputation.......4Computation ...........4 4. Detailed Inter-Area Specific Requirements onPCECP..........5PCECP ..............5 4.1. Control and Recording of AreaCrossing......................5Crossing .....................5 4.2. AreaRecording..............................................5Recording .............................................6 4.3. Strict Explicit Path and LoosePath.........................6Path ........................6 4.4.PCE-listPCE List Enforcement and Recording inMultiple PCE Computation...............................................6Multiple-PCE Computation ................................................6 4.5. Inclusion of Area IDs inRequest............................6Request ...........................7 4.6. AreaInclusion/Exclusion....................................7Inclusion/Exclusion ...................................7 4.7.Inter-areaInter-Area Diverse Pathcomputation.........................7Computation ........................7 4.8.Inter-area Policies.........................................8Inter-Area Policies ........................................8 4.9. LoopAvoidance..............................................8Avoidance .............................................9 5. ManageabilityConsiderations................................8Considerations ....................................9 6. SecurityConsiderations.....................................8Considerations .........................................9 7.Acknowledgments.............................................9Acknowledgments .................................................9 8.IANA Considerations.........................................9 9. References..................................................9 9.1.References .....................................................10 8.1. NormativeReferences........................................9 9.2.References ......................................10 8.2. InformativeReferences......................................9 10. Editor Address:.............................................9 11. Contributors' Addresses....................................10 12. Intellectual Property Statement............................11References ....................................10 9. Contributors ...................................................10 1.Terminology LSR: Label Switching Router. LSP: MPLS Label Switched Path. TE-LSP: Traffic Engineering 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 areas (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: RSVP-TE Explicit Route Object. It encodes the explicit path followed by a TE-LSP. 2.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 ofinter- areainter-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.IndeedIndeed, 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 thePCE basedPCE-based architecture [RFC4655]. The computation of optimalinter-areainter- 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. 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 forsuchsuch 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 amechanismTE-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 arediscussedto be interpreted as described in[RFC4674].[RFC2119]. 3. Motivations forPCE-basedPCE-Based Inter-Area Path Computation IGP hierarchy enables improved IGPscalability,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 ownareaarea, but only information about reachability to destinations in otherareas._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 aper domainper-domain path computation([PD-COMP]).[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 constrainedpath;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[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. ThePCE basedPCE-based architecture [RFC4655] is well suited to inter-area pathcomputation, as itcomputation. 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. There are two main approaches for the computation of an inter-area optimal path: -Single PCESingle-PCE computation: The path is computed by a single PCE that has topology visibility in all areas and can compute anend- to-endend-to-end optimal constrained path on its own. -Multiple PCEMultiple-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-basedapproach,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(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 isallowed or not.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.HenceHence, 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.HenceHence, the response message MUST allow identifying the crossed areas.AlsoAlso, the response message MUST allow segmenting the returned path and marking each segment so that it is possible to tell which piece of the pathlielies 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.(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.HenceHence, the PCECP request message MUST allow indicating whether a Strict Explicit Path is required/desired. 4.4.PCE-listPCE List Enforcement and Recording inMultiple PCEMultiple-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 eachareaarea, the preferred PCE should be tried before another PCEbeis selected. Note that if there is no preferred PCE indicated for an area, any PCE in that area may be used.HenceHence, 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 areahavehas knowledge of PCEs in other areas. This could rely on configuration or on a PCE discovery mechanism, allowing discovery across area boundaries (see [RFC4674]).AlsoAlso, it would be useful to know the list of PCEswhichthat effectively participated in the computation.HenceHence, the request message MUST support a request for PCErecordingrecording, 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.HenceHence, 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. 4.5. Inclusion of Area IDs in RequestThe knowledgeKnowledge 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.(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 othermean.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 asituationsituation, it would be usefulthatfor a PCCindicatesto indicate the source and destination area IDs in its request message. For thatpurposepurpose, 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 usefulthatfor the request message to indicate one or more area(s) that must be followed by the path to be computed. It may also be usefulthatfor the request message to indicate one or more area(s) that must be avoided by the path to be computed(e.g.(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).HenceHence, 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-areaInter-Area Diverse PathcomputationComputation 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- Per-area diversity (intra-area path segments are link,nodenode, or SRLG disjoint)-Inter-area- Inter-area diversity (end-to-end inter-area paths are link,nodenode, or SRLG disjoint) Note that two paths may be disjoint in the backbone area but non- disjoint in peripheral areas. Also two paths may benode disjointnode-disjoint within areas but may share ABRs, in which case path segments within an area arenode disjointnode-disjoint, but end-to-end paths are notnode-disjoint.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 aper- areaper-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-areaInter-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 amultiple PCEmultiple-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]).[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.AlsoAlso, the returned path in a response message MUST be loop free. 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. ThePCEPPCECP PCC MIB module MUST also allow recording the performances of a PCE chain (minimum,maximummaximum, and average responsetime),times), in case of multiple-PCE inter-area path computation.A built inIt is really important, for diagnostictool MUST be definedand troubleshooting reasons, to monitor the availability and performances ofaeach PCEchain, in caseofmultiple-PCEa 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 theminimum maximumavailability of each PCE of the chain as well as its minimum, maximum, and average responsetime globally for the chain, and on a per PCE basis.times. 6. Security Considerations IGP areas are administrated by the same entity.HenceHence, theinter-areainter- area application does not imply a new trustmodel,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, DimitriPapadimitriouPapadimitriou, and Lou Berger for their useful comments and suggestions.8. IANA Considerations This document makes no requestsThanks also to Ross Callon, Catherine Meadow, and Dan Romascanu forIANA action. 9.their review during the final stages of publication. 8. References9.1.8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4105] LeRoux J.L., Vasseur J.P.,Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle,J., et al.Ed., "Requirements forinter-area MPLS-TE"Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4655]A.Farrel,JP. VasseurA., Vasseur, J.-P., and J. Ash,"Path"A Path Computation Element(PCE) Based(PCE)-Based Architecture",RFC4655,RFC 4655, August 2006. [RFC4657]J.Ash,J.LJ., Ed., and J. LeRoux et. al., "PCERoux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements",RFC4657,RFC 4657, September 2006.9.2.8.2. Informative References [RFC4674]J.L.LeRoux et. al.,Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery",RFC4674,RFC 4674, October 2006. [PD-COMP] Vasseur, J.P., Ed., Ayyangar, A., Ed., and R. Zhang,R.,"A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP)",workWork inprogress.Progress, April 2007. [PCE-POL-FMWK]I.Bryskin,D.I., Papadimitriou,L.D., Berger"Policy- EnabledL., and J. Ash, "Policy-Enabled Path Computation Framework",draft-ietf-pce-policy-enabled- path-comp, workWork inprogress. [METRIC]Progress, March 2007. [RFC3785] LeFaucheur et al.,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",RFC3785,BCP 87, RFC 3785, May 2004.10. Editor Address: Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@orange-ftgroup.com 11. Contributors' Addresses9. Contributors Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578Email: gash@att.comEMail: gash5107@yahoo.com Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145Email: nabil.bitar@verizon.comEMail: nabil.n.bitar@verizon.com Dean Cheng Cisco Systems Inc. 3700 Cisco Way SanJoseJose, CA 95134 USA Phone: +1 408 527 0677Email:EMail: dcheng@cisco.com Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103Email:EMail: ke-kumaki@kddi.com Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585, JAPANEmail: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. ChinaEmail:EMail: zhangrenhai@huawei.com12.Editor's Address Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE EMail: jeanlouis.leroux@orange-ftgroup.com 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 PropertyStatementThe 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.Disclaimer of Validity This document andAcknowledgement Funding for theinformation 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. Copyright Statement Copyright (C) The IETF Trust (2006). This documentRFC Editor function issubject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein,currently provided by theauthors retain all their rights.Internet Society.