Network Working Group Internet Draft K. Kumaki, Ed. Category: standard track KDDI R&D Labs Created: April 18, 2008 T. Murai, Ed. Expires: October 18, 2008 FURUKAWA NETWORK SOLUTION CORP. PCEP extensions for a BGP/MPLS IP-VPN draft-kumaki-murai-pce-pcep-extension-l3vpn-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. Copyright Notice Copyright (C) The IETF Trust (2008). 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. K.Kumaki and T.Murai [Page 1] draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008 Table of Contents 1. Introduction..................................................2 2. Problem Statement.............................................3 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 5. Security Considerations.......................................6 6. IANA Considerations...........................................6 7. References....................................................6 7.1 Normative References.......................................6 7.2 Informative References.....................................6 8. Acknowledgments................................................7 9. Author's Addresses.............................................7 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 [PCEP]. Service Providers have requirements to support PCE architecture for a customer MPLS TE LSP establishment in the context of a BGP/MPLS IP- VPNs. [E2E-RSVP-TE] In order to establish a customer MPLS TE LSP over BGP/MPLS IP-VPNs, PCEs need to know the VPNv4/VPNv6 tail-end address 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. [BRPC] 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 a PE will be a PCE. In this way, it is advantageous to use PCE 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 5.1 and the specific procedure is described in section 5.2. K.Kumaki and T.Murai [Page 2] draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008 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 [PCEP] (i.e., the K.Kumaki and T.Murai [Page 3] draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008 message for VPN1 and the message for VPN2). Therefore, PCE2 can not calculate an appropriate TE LSP between CEs per VPN. In order to distinguish between the VPN1 PCReq message and the VPN2 PCReq message, an identifier in PCReq 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 [PCEP] 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: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ K.Kumaki and T.Murai [Page 4] draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008 | | | 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) When an ingress PE(PCE) received 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 K.Kumaki and T.Murai [Page 5] draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008 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) received 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. 5. Security Considerations We will write security considerations in next version. 6. IANA Considerations IANA will assign END-POINTS Object-Types for VPN-IPv4 address and VPN-IPv6 address. 7. References 7.1 Normative References [PCEP] Vasseur, J.-P., et al., "Path Computation Element(PCE) communication Protocol (PCEP) - Version 1", draft-ietf- pce-pcep (Work in Progress), March 2008. 7.2 Informative References [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "Path Computation Element (PCE) Architecture", RFC 4655, August 2006. K.Kumaki and T.Murai [Page 6] draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008 [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), April 2008. [BRPC] Vasseur, J.-P., et al., "A Backward Recursive PCE- based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc (Work in Progress), April 2008. [PCE-BGP-VPN] Kumaki, K. and Murai, "BGP protocol extensions for Path Computation Element (PCE) Discovery in a BGP/MPLS IP- VPN ", draft-kumaki-pce-bgp-disco-attribute (Work in Progress), April 2008. 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 R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, 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 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 K.Kumaki and T.Murai [Page 7] draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008 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 provided by the IETF Administrative Support Activity (IASA). K.Kumaki and T.Murai [Page 8]