Network Working Group M. Chaitou Internet Draft J.L. Le Roux Intended status: Standard Track France Telecom Expires: August 2008 Zafar Ali Cisco Systems February 18, 2008 Path Computation Element communication Protocol (PCEP) Extensions for Point to Multipoint Label Switched Paths (LSPs) draft-chaitou-pce-p2mp-ext-00.txt Status of this Memo By 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 of the Internet Engineering 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 maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 1] Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008 Abstract The Path Computation Element communication Protocol (PCEP) enables computing point-to-point Traffic Engineered (TE) paths in Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. This document describes extensions to PCEP in order to support the computation of point-to-multipoint (P2MP) Traffic Engineered (TE) paths. 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....................................................3 2. Introduction...................................................3 3. PCEP extensions................................................4 3.1. PCReq message format......................................4 3.2. PCRep message format......................................5 3.3. New SVEC object flag......................................5 3.3.1. Elements of procedure................................6 3.4. Objective functions.......................................6 3.5. New metric object types...................................7 3.6. P2MP TE path re-optimization request......................7 3.6.1. The Non-Modifiable Path flag.........................7 3.7. Adding/pruning leaves.....................................8 3.8. Branch nodes..............................................8 3.9. Route compression indication..............................8 3.10. Synchronization of P2MP TE path computation requests.....8 4. Security considerations........................................8 5. IANA considerations............................................9 6. References.....................................................9 7. Author's Addresses:...........................................10 8. Intellectual Property Statement...............................10 Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 2] Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008 1. Terminology Terminology used in this document TE LSP: Traffic Engineered Label Switched Path. LSR: Label Switch Router. OF: Objective Function: A set of one or more optimization criterion (criteria) used for the computation of a single path (e.g. path cost minimization), or the synchronized computation of a set of paths (e.g. aggregate bandwidth consumption minimization, etc.). PCC: Path Computation Client: Any client application requesting a path computation to be performed by a Path Computation Element. 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. PCEP: Path Computation Element communication Protocol. P2MP: Point-to-MultiPoint. P2P: Point-to-Point. 2. Introduction The Path Computation Element defined in [RFC4655] is an entity capable of computing TE LSP paths based on a network graph, and applying computational constraints. A PCE serves path computation requests sent by Path Computation Clients (PCC). The PCE communication Protocol (PCEP), defined in [PCEP], allows for communication between a PCC and a PCE or between two PCEs, in compliance with requirements and guidelines set forth in [RFC4657]. Such interactions include path computation requests and path computation replies. At present, PCEP supports P2P TE path computations. As mentioned in [PCE-P2MP-REQ], it may be useful to rely on one or more PCE for the computation of P2MP paths, for the same reasons as for P2P path, that is to handle complex P2MP computations as well as to support inter domain P2MP computation. Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 3] Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008 To address the above mentioned requirement of P2MP path computation in [P2MP-PCE-REQ], this document defines extensions to PCEP [PCEP]. Specifically, the format of PCReq and PCRep messages is extended to support P2MP path computation requests and replies. Two new objective functions are defined for trees, namely SPT (Shortest Path Tree) and MCT (Minimum Cost Tree), which define the optimization criteria that may apply when computing a tree. Also three new metric types are defined in order to indicate the cost of a tree. 3. PCEP extensions This section defines extensions to PCEP ([PCEP]) so as to support the communication of P2MP path computation requests and replies. In order to minimize extensions to PCEP and maximize backward compatibility, a P2MP request is represented as a synchronized set of P2P path requests from the root to each leaf following synchronization procedures defined in [PCEP]. For that purpose a new synchronization flag, the P2MP flag is defined. In order to request the computation of a P2MP path towards a set of leaves the PCC will issue one or more PCReq message including a set of P2P path requests towards each leaf synchronized using the SVEC object, with a new flag indicating P2MP synchronization. 3.1. PCReq message format A request for a P2MP path computation is built as a synchronized set of P2P path request from the root to each leaf. The TE constraints and objective function MUST directly follow the SVEC object, and MUST NOT repeated for each elementary request. The PCReq message for a particular P2MP path computation request has the following format: ::= [] [] [OF] [] [] where: ::=[] ::= Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 4] Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008 [] [] [] where: ::=[] Note that a P2MP request may be divided into multiple PCReq messages following synchronization procedures defined in [PCEP]. 3.2. PCRep message format A PCRep message for a P2MP path is comprised of a set of synchronized P2P replies including the P2P path towards each leaf. The format of the PCRep message for a P2MP request is as follows: ::= [] [] [OF] [] [] where: ::=[] ::= [] [] ::=[] ::= [] [] where: ::=[ 3.3. New SVEC object flag A new bit flag, referred to as the P2MP flag, is defined in the SVEC object, so as to indicate within a PCReq message a request for a P2MP path computation and within a PCRep message to indicate a reply for a P2MP computation request. Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 5] Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008 Note that the ability of a PCE to support P2MP TE path computation requests may be dynamically discovered by the PCC(s) by means of PCE capability discovery protocols [RFC5088], [RFC5089]. 3.3.1. Elements of procedure On receipt of a PCReq message with the P2MP flag in the SVEC object set, the PCE has to proceed as follows: o If the PCE understands the P2MP flag and supports computing P2MP paths, then the PCE starts P2MP path computation. o If the PCE understands the P2MP flag but does not support the computation of P2MP paths, it must send a PCErr message with a new error type "P2MP path computation not supported" (defined in this document). o If the PCE does not understand the P2MP flag then the PCE MUST send a PCErr message with a new error type "Unknown SVEC flag" (defined in this document). 3.4. Objective functions Six objective functions have been defined in [PCE-OF] for P2P path computation. This document defines two additional objective functions, namely SPT (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP path computation. Hence two new objective function codes have to be defined. The description of the two new objective functions is as follows. Objective Function Code: 7 (suggested value, to be assigned by IANA) Name: Shortest Path Tree (SPT) Description: Minimize the maximum source-to-leaf cost with respect to a specific metric (e.g. TE or IGP metric) Objective Function Code: 8 (suggested value, to be assigned by IANA) Name: Minimum Cost Tree (MCT) Description: Minimize the total cost of the tree, that is the sum of the costs of tree links, with respect to a specific metric. Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 6] Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008 Processing these two new objective functions is subject to the rules defined in [PCE-OF]. 3.5. New metric object types There are three types defined for the object in [PCEP], namely, the IGP metric, the TE metric and the hop count metric. This document defines three other types for the object: the P2MP IGP metric, the P2MP TE metric, and the P2MP Hop Count metric. They encode the sum of the metrics of all links of the tree. We propose the following values for these new metric types (to be assigned by IANA): o P2MP IGP metric: T=4 o P2MP TE metric: T=5 o P2MP hop count metric: T=6 These three new metric objects MUST follow the SVEC object in a PCReq or PCRep message and MUST not appear for each elementary P2P request (i.e. they MUST not appear after a RP object). 3.6. P2MP TE path re-optimization request A request for the re-optimization of a P2MP path is issued with a PCReq message including all the P2P path requests towards each leaf with the R bit set in the objects and the old P2P paths carried within the . As indicated in [PCE-P2MP-REQ] it must be possible to indicate in a request whether a P2P path towards a leaf can be modified or not and in a response whether a P2P path has been modified or not. For that purpose we introduce a new flag within the object. 3.6.1. The Non-Modifiable Path flag A new flag of the object (specified in [PCEP]) is defined in this document. The IANA is requested to make the following allocation (suggested value): Bit Hex Name Reference Number 14 0x02000 NP (Non-modifiable Path) (this document) Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 7] Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008 When cleared within a PCReq message this indicates that the P2P path can be modified and when cleared within a PCRep message this indicates that the P2P path has been modified. When set in a PCReq message this indicates that the P2P path cannot be modified, and when set within a PCRep message this indicates that the P2P path has not been modified. The flag is meaningful only if the R flag is set. 3.7. Adding/pruning leaves To request the modification of an existing P2MP tree that includes new leaves, the request message MUST include the set of new P2P path requests with the R flag cleared in the objects as well as all the existing P2P path requests with the R flag set in the objects with the corresponding . If an existing P2P path must not be changed the NP bit MUST be set in the corresponding object. To request the modification of a P2MP tree that looses some leaves the PCReq message MUST include only the set of P2P path requests corresponding to the remaining leaves. 3.8. Branch nodes Before computing the P2MP path, a PCE must be provided means to know which nodes in the network are capable of acting as branch LSRs. A PCE can discover such capability by using the mechanisms defined in [NODE- CAP]. 3.9. Route compression indication To be completed. 3.10. Synchronization of P2MP TE path computation requests It is possible to synchronize the computation of n, n>=2, P2MP path requests by including in a PCReq messages (n+1) objects. Each of the first n objects contains the request-id-numbers that represent all the P2P paths that constitute one P2MP TE LSP. The last object contains n request-id-numbers where each request-id-number represents a P2P request belonging to a different P2MP path, following procedures for hierarchical synchronization defined in [PCE-SVEC-LIST]. 4. Security considerations To be completed. Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 8] Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008 5. IANA considerations To be completed. 6. References [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006. [RFC4655] Farrel, A., Vasseur, J.-P., " A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J., Le Roux, J.L.," Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., Yasukawa, S. "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point- to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [NODE-CAP] Vasseur, J.-P., Le Roux, J.L., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007 [RFC5088] Le Roux, J.L., Vasseur, J.-P., Ikejiri, Y., Zhang, R., "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, J.L., Vasseur, J.-P., Ikejiri, Y., Zhang, R., "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. [PCEP] Vasseur, J.-P., Le Roux, J.L., "Path Computation Element (PCE) communication Protocol (PCEP)", draft-ietf-pce-pcep, work in progress. [PCE-P2MP-REQ] Yasukawa, S., "PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", draft-yasukawa-pce-p2mp-req, work in progress. [PCE-OF] Le Roux, J.L., Vasseur, J.-P., Lee, Y. "Encoding of Objective Functions in Path Computation Element (PCE) communication and discovery protocols", draft-ietf-pce-of, work in progress. Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 9] Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008 [PCE-SVEC-LIST] Nishioka, I., King, D., "The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations", draft-nishioka-pce-svec-list, work in progress. 7. Author's Addresses: Mohamad Chaitou France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: Mohamad.Chaitou@orange-ftgroup.com Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: Jeanlouis.Leroux@orange-ftgroup.com Zafar Ali Cisco systems, Inc., 2000 Innovation Drive Kanata, Ontario Canada K2K 3E8 Phone: 613 254 3498 Email: zali@cisco.com 8. Intellectual Property Statement 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 Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 10] Internet-Draft draft-chaitou-pce-p2mp-ext-00 February 2008 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 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. 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. Chaitou, Le Roux, Ali Expires August 18, 2008 [Page 11]