Network Working Group Internet Draft K. Kumaki, Ed. Category: standards track KDDI Corporation Created: October 23, 2009 T. Murai, Ed. Expires: April 23, 2010 FURUKAWA NETWORK SOLUTION CORP. T. Yamagata KDDI Corporation C. Sasaki KDDI R&D Labs PCEP extensions for a BGP/MPLS IP-VPN draft-kumaki-murai-pce-pcep-extension-l3vpn-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. Abstract It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. In such a scenario, it is advantageous to use PCE to calculate customer MPLS TE LSPs. This document defines PCEP extensions for BGP/MPLS IP- VPNs. Table of Contents 1. Introduction..................................................2 2. Problem Statement.............................................3 K.Kumaki, et al. [Page 1] draft-kumaki-murai-pce-pcep-extension-l3vpn-04 October 2009 3. Terminology...................................................4 4. Protocol Extensions and Procedures............................4 4.1 Type Definition...........................................4 4.2 Handling..................................................5 4.2.1 PCReq message Processing at Ingress PE (PCE)............5 4.2.2 PCReq message Processing at Egress PE (PCE).............6 4.2.3 PCRep message Processing at Egress PE (PCE).............6 4.2.4 PCRep message Processing at Ingress PE (PCE)............6 5. Security Considerations.......................................7 6. IANA Considerations...........................................7 7. References....................................................7 7.1 Normative References......................................7 7.2 Informative References....................................7 8. Acknowledgments...............................................8 9. Author's Addresses............................................8 1. Introduction [RFC4655] describes the motivations and architecture for a Path Computation Element (PCE)-based path computation model for Multi Protocol Label Switching (MPLS) / Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs). In this model, path computation requests are issued by a PCC to PCE that may be composite or external. In case the PCC and PCE are not composite, a request/response communication protocol is required to carry the request and return the response. The requirements for such a communication protocol are described in [RFC4657]. The communication protocol between PCC and PCE, and between PCEs, is defined in [RFC5440]. Service Providers have requirements to support PCE architecture for a CE-CE MPLS TE LSP / a PE-PE MPLS TE LSP establishments in the context of a BGP/MPLS IP-VPNs. [E2E-RSVP-TE][PCE-VPN-REQ] In order to establish a customer MPLS TE LSP over BGP/MPLS IP-VPNs, PCEs need to know the VPNv4/VPNv6 tail-end addresses or PCE addresses for this tail-end address to forward to them, and finally need to calculate the end-to-end customer MPLS TE LSP. [RFC5441] can be used as an example of calculate methods for a customer MPLS TE LSP. Also, in order to discover these PCEs in BGP/MPLS IP-VPNs, [PCE-BGP-VPN] is proposed. Note that it is assumed that PCE functions are included in PE. In this way, it is advantageous to use PCEs to calculate customer MPLS TE LSPs in the context of BGP/MPLS IP-VPNs. This document defines new object types in END-POINTS object to calculate the end-to-end customer MPLS TE LSP in the context of BGP/IP-VPNs and describes a procedure of PCEP message including new object types. The new object types are defined in section 4.1 and the specific procedure is described in section 4.2. K.Kumaki, et al. [Page 2] draft-kumaki-murai-pce-pcep-extension-l3vpn-04 October 2009 2. Problem Statement PCEs in the context of BGP/MPLS IP-VPNs are shown in figure 1. Here, we make the following set of assumptions. 1. VPN1 and VPN2 are completely different customers. 2. CE0 and CE4 are head-end routers. 3. CE3 and CE7 are tail-end routers. 4. A same address (e.g., 192.0.2.1) is assigned at CE3 and CE7. <----------------a customer MPLS TE LSP for VPN1------------> (PCE1) (PCE2) ............. ............. . --- --- . --- --- --- --- . --- --- . .|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|. . --- --- . --- --- --- --- . --- --- . ............. | | ............. (VPN1) | | (VPN1) | | ............. | | ............. . --- --- . | | . --- --- . .|CE4| |CE5|-------+ +-------|CE6| |CE7|. . --- --- . . --- --- . ............. ............. (VPN2) (VPN2) <---------------a customer MPLS TE LSP for VPN2-------------> ^ ^ | | vrf instance vrf instance <--customer--> <------BGP/MPLS IP-VPN------> <--customer-> network network Figure 1 PCEs in the context of BGP/MPLS IP-VPNs Consider that customers in VPN1 and VPN2 establish a customer MPLS TE LSP between their sites (i.e., between CE0 and CE3, between CE4 and CE7) In this case, CE0 and CE4 send a PCReq message to PCE1 to establish customer MPLS TE LSPs between CE0 and CE3, CE4 and CE7, respectively. After receiving these messages, PE1 can identify each PCReq message (i.e., a message for VPN1 and a message for VPN2) from each incoming interface. Afterwards, PCE1 forwards the messages to PCE2 by BGP discovery [PCE-BGP-VPN]. PE2, however, can not identify each PCReq message from current specification of [RFC5440] (i.e., the K.Kumaki, et al. [Page 3] draft-kumaki-murai-pce-pcep-extension-l3vpn-04 October 2009 message for VPN1 and the message for VPN2). Therefore, PCE2 can not calculate an appropriate TE LSP between CEs per VPN. Also, PCRep messages per VPN can not be identified at PCE1 due to the above reason. In order to distinguish between the VPN1 PCReq/PCRep messages and the VPN2 PCReq/PCRep messages, an identifier in PCReq/PCRep messages is required. In this document, new object types in END-POINTS object as an identifier are defined to distinguish PCReq messages per VPN in the context of BGP/MPLS IP-VPNs. 3. Terminology LSP: Label Switched Path TE LSP: Traffic Engineering Label Switched Path MPLS TE LSP: Multi Protocol Label Switching TE LSP Customer MPLS TE LSP: an end-to-end MPLS TE LSP for customers 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. PE: Provider Edge: Provider Edge Equipment that has direct connections to CEs from the Layer3 point of view. 4. Protocol Extensions and Procedures 4.1 Type Definition Two new Object-Types for VPN-IPv4 address and VPN-IPv6 address in END-POINTS object described in [RFC5440] are defined. END-POINTS Object-Type is to be assigned by IANA (recommended value=3 for VPN-IPv4 and 4 for VPN-IPv6) The format of the END-POINTS object body for VPN-IPv4 (Object- Type=3) is as follows: K.Kumaki, et al. [Page 4] draft-kumaki-murai-pce-pcep-extension-l3vpn-04 October 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source VPN-IPv4 address (12 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination VPN-IPv4 address (12 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the END-POINTS object body for VPN-IPv6 (Object- Type=4) is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Source VPN-IPv6 address (24 bytes) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Destination VPN-IPv6 address (24 bytes) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Handling It assumes that ingress PEs and egress PEs in the context of BGP/MPLS IP-VPNs have PCE capabilities. It is considered that ingress PEs and egress PEs are not PCEs (e.g., external PCE models). However, this topic is for further study. 4.2.1 PCReq message Processing at Ingress PE (PCE) K.Kumaki, et al. [Page 5] draft-kumaki-murai-pce-pcep-extension-l3vpn-04 October 2009 When an ingress PE (PCE) receives a PCReq message from a PCC/PCE, it can distinguish a VRF instance that is associated with an incoming interface. The ingress PE deals with a destination IPv4/IPv6 address in END-POINTS object as a destination VPN-IPv4/VPN-IPv6 address in the VRF instance. Afterwards, the destination VPN-IPv4/VPN-IPv6 address is looked up in the context of VRF instance, and the BGP next-hop for this destination is identified. The destination VPN- IPv4/VPN-IPv6 address in a new END-POINTS object consists of the original destination IPv4/IPv6 address in END-POINTS object and the Route Distinguisher (RD). Note that the RD is specified by the BGP next-hop for the destination VPN-IPv4/VPN-IPv6 address. The source VPN-IPv4/VPN-IPv6 address in the new END-POINTS object consists of the original IPv4/IPv6 address in END-POINTS object and the RD. Note that the RD is used by this ingress PE to advertise customer's prefix including the source VPN-IPv4/VPN-IPv6 address into the vrf instance. The ingress PE will send the PCReq message to next PCE (maybe an egress PE for BGP/MPLS IP-VPNs) if it needs to send it. Finally, the ingress PE should replace the incoming END-POINTS object from PCC/PCE into the new END-POINTS object. 4.2.2 PCReq message Processing at Egress PE (PCE) When an egress PE (PCE) receives a PCReq message from an ingress PE(PCE), it can distinguish a VRF instance from the destination VPN- IPv4/VPN-IPv6 address in the new END-POINTS object. The egress PE will send a PCReq message to next PCE if it needs to send it. Afterwards, the egress PE should remove the RD from the source and the destination VPN-IPv4/VPN-IPv6 addresses in the new END-POINTS object received from the ingress PE. Finally, the source and the destination addresses in the original END-POINTS object are IPv4/IPv6 ones. The egress PE should store the new END-POINTS object for a PCReq message in a VRF instance. 4.2.3 PCRep message Processing at Egress PE (PCE) When an egress PE (PCE) receives a PCRep message for a PCReq message from a previous PCE (i.e. CE), it can look up the new END-POINTS object associated with the PCReq message for the PCRep message. The egress PE performs a path computation. Note that the path computation procedure itself is out of scope in this document. Afterwards, the egress PE adds the new END-POINTS object in a PCRep message and send it to an ingress PE. 4.2.4 PCRep message Processing at Ingress PE (PCE) When an ingress PE (PCE) receives a PCRep message for a PCReq message from an egress PE (PCE), it can distinguish a VRF instance from the source VPN-IPv4/VPN-IPv6 address in the new END-POINTS object. K.Kumaki, et al. [Page 6] draft-kumaki-murai-pce-pcep-extension-l3vpn-04 October 2009 Therefore, it is now possible to generate a PCRep message to send to an appropriate PCC/PCE. 5. Security Considerations This document defines PCEP extensions for BGP/MPLS IP-VPNs. Hence the security of the PCE extensions relies on the security of PCEP. The security issues are described in the existing PCEP. [RFC5440] 6. IANA Considerations IANA will assign END-POINTS Object-Types for VPN-IPv4 address and VPN-IPv6 address. 7. References 7.1 Normative References [RFC5440] Vasseur, J.-P., et al., "Path Computation Element(PCE) communication Protocol (PCEP) - Version 1", RFC5440, March 2009. 7.2 Informative References [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "Path Computation Element (PCE) Architecture", RFC 4655, August 2006. [RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic Requirements", RFC4657, September 2006. [E2E-RSVP-TE] Kumaki, K., Zhang, R. and Kamite, Y., "Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts (Work in Progress), July 2009. [PCE-VPN-REQ] Yasukawa, S. and Farrel, A., "PCC-PCE Communication Requirements for VPNs", draft-ietf-pce-vpn-req (Work in Progress), March 2009. [RFC5441] Vasseur, J.-P., et al., "A Backward Recursive PCE- based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths", RFC5441, April 2009. [PCE-BGP-VPN] Kumaki, K. and Murai, "BGP protocol extensions for Path Computation Element (PCE) Discovery in a BGP/MPLS IP- K.Kumaki, et al. [Page 7] draft-kumaki-murai-pce-pcep-extension-l3vpn-04 October 2009 VPN ", draft-kumaki-pce-bgp-disco-attribute (Work in Progress), July 2009. 8. Acknowledgments The author would like to express thanks to Makoto Nakamura for his helpful and useful comments and feedback. 9. Author's Addresses Kenji Kumaki (Editor) KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Email: ke-kumaki@kddi.com Tomoki Murai (Editor) FURUKAWA NETWORK SOLUTION CORP. 5-1-9, HIGASHI-YAWATA, HIRATSUKA Kanagawa 254-0016, JAPAN Email: murai@fnsc.co.jp Tomohiro Yamagata KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Email: to-yamagata@kddi.com Chikara Sasaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, JAPAN Email: ch-sasaki@kddilabs.jp Intellectual Property Statement The IETF Trust 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 any IETF 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. Copies of Intellectual Property 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 K.Kumaki, et al. [Page 8] draft-kumaki-murai-pce-pcep-extension-l3vpn-04 October 2009 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. K.Kumaki, et al. [Page 9] draft-kumaki-murai-pce-pcep-extension-l3vpn-04 October 2009 Full Copyright Statement Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. K.Kumaki, et al. [Page 10]