Network Working Group Internet Draft K. Kumaki, Ed. Intended Status: Standards Track KDDI Corporation Expires: April 30, 2012 T. Murai Furukawa Network Solutions Corp. D. Dhody Huawei Technology P. Jiang KDDI R&D Labs October 30, 2011 PCEP extensions for a BGP/MPLS IP-VPN draft-kumaki-murai-pce-pcep-extension-l3vpn-08.txt Abstract IP Virtual Private Networks (IP-VPNs) allow Service Providers to offer customers connectivity between sites across an IP Backbone. These VPNs can be supported using BGP/MPLS and the connections can be created by using MPLS Traffic Engineered (TE) Label Switched Paths (LSPs). The paths of these LSPs must be computed to provide the connectivity between customer sites. Path selection may be dependent on a variety of factors including traffic engineering constraints and bandwidth requirements. It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs for interconnectivity between BGP/MPLS IP-VPN sites. The Path Computation Element (PCE) can determine the optimal paths of TE LSPs within an MPLS network. This document defines the PCEP extensions for the dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites. 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 This Internet-Draft will expire on April 30, 2012. K.Kumaki, et al. [Page 1] draft-kumaki-murai-pce-pcep-extension-l3vpn-08 October 2011 Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction.................................................3 2. Problem Statement............................................4 3. Protocol Extensions and Procedures...........................5 3.1 Type Definition..........................................5 3.2 PCE Capabilities.........................................6 3.2.1 PCReq message Processing at Ingress PE (PCE)...........6 3.2.2 PCReq message Processing at Egress PE (PCE)............7 3.2.3 PCRep message Processing at Egress PE (PCE)............7 3.2.4 PCRep message Processing at Ingress PE (PCE)...........7 4. Security Considerations......................................8 5. IANA Considerations..........................................8 6. References...................................................8 6.1 Normative References.....................................8 6.2 Informative References...................................8 7. Acknowledgments..............................................9 8. Authors' Addresses...........................................9 K.Kumaki, et al. [Page 2] draft-kumaki-murai-pce-pcep-extension-l3vpn-08 October 2011 1. Introduction [RFC4364] describes how a Service Provider could use an IP backbone to provide IP Virtual Private Networks (VPNs) to its customers. Each VPN contains at least one Customer Edge (CE) router which is attached to a Provider (PE) router. It is possible for CE routers to be attached to multiple PE routers. The Border Gateway Protocol (BGP) [RFC4271] can be used to exchange VPN route information between the PE routers. [RFC4655] describes the motivation and architecture for the Path Computation Element (PCE). The PCE can be used to compute the routes for MPLS and GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs). A path computation request is issued by a Path Computation Client (PCC) to the PCE. The communication protocol between PCCs and PCEs is called the Path Computation Element Communication Protocol (PCEP) and is defined in [RFC5440]. This document examines why it would be advantageous to use the PCE architecture to establish connectivity between IP/MPLS VPNs and defines extensions to PCEP to support that function. The requirements for establishing connectivity between CE and PE sites are defined in [RFC5824]. The requirements placed on PCEP for the use of a PCE in a variety of VPN environments are set out in [PCE-VPN-REQ]. This work only examines a small subset of the requirements from [PCE-VPN-REQ] because it limits the use of PCEs to specific objectives in BGP/MPLS IP-VPNs. In order to establish a customer MPLS TE LSP over a BGP/MPLS IP-VPN, a PCE needs to know the VPNv4/VPNv6 tail-end addresses (source and destination) and the addresses for the PEs that provide access to them. Additionally the PCE needs to calculate the route of an end-to-end customer MPLS TE LSP. [RFC5441] describes the Backward Recursive Path Computation (BRPC) technique that could be used to compute the route of a customer MPLS TE LSP. In order to discover PCEs participating in a BGP/MPLS IP-VPNs, [PCE-BGP-VPN] is proposed, but this information could be configured or discovered through another means. Note that it is assumed that PCE functions are normally included in PE routers they could also be placed in other nodes that are fully accessible to all PCCs in the VPN. This document defines new object types in the PCEP END-POINTS object to calculate the end-to-end customer MPLS TE LSP used for BGP/IP-VPNs, and describes a procedure for the PCEP message processing. The new object types are defined in Section 3.1 and the specific procedure is described in Section 3.2. K.Kumaki, et al. [Page 3] draft-kumaki-murai-pce-pcep-extension-l3vpn-08 October 2011 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. C0 and C4 are head-end routers. 3. C3 and C7 are tail-end routers. 4. The same address (e.g., 192.0.2.1) is assigned to both C3 and C7. <---------------A customer MPLS TE LSP for VPN1-----------> (PCE1) (PCE2) ............ ............ . -- --- . --- --- --- --- . --- -- . .|C0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |C3|. . -- --- . --- --- --- --- . --- -- . ............ | | ............ (VPN1) | | (VPN1) | | ............ | | ............ . -- --- . | | . --- -- . .|C4| |CE5|-------+ +-------|CE6| |C7|. . -- --- . . --- -- . ............ ............ (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 would like to establish customer MPLS TE LSPs between their sites (i.e., between CE0 and CE3, and between CE4 and CE7). The following PCEP requests will occur: 1. C0 send a PCReq message to PCE1 to compute a path for a customer MPLS TE LSPs between C0 and C3. 2. C4 send a PCReq message to PCE1 to compute a path for a customer MPLS TE LSPs between C4 and C7. K.Kumaki, et al. [Page 4] draft-kumaki-murai-pce-pcep-extension-l3vpn-08 October 2011 PCE1 (PE1) is able to distinguish to which VPN the received requests apply from the interface over which the requests were received. PCE1 can forward the request to PCE2 having been configured with or discovered ([PCE-BGP-VPN]) the existence and address of PCE2. However, based on the PCEP specification defined in [RFC5440] and the fact that the two messages come from the same cooperating PCE (PCE1), PCE2 cannot determine to which VPN the computation requests apply. Therefore, PCE2 cannot calculate the requested paths. In order to distinguish between the VPN1 PCReq messages and the VPN2 PCReq messages, a VPN identifier is required in PCReq messages. This identifier can be duplicated into the PCRep messages to achieve symmetry and allow cross-checking. This document defines a new object type for the END-POINTS object to be used to facilitate VPN identification. 3. Protocol Extensions and Procedures The new END-POINTS Object-Types for the PCEP request allow the PCE to distinguish the VRF instance that is associated with the incoming PCEP message. 3.1 Type Definition The END-POINTS Object is defined in [RFC5440]. Two new Object-Types are defined to carry VPN-IPv4 addresses and VPN-IPv6 addresses. END-POINTS Object-Type is to be assigned by IANA (recommended values: 3 for VPN-IPv4 and 4 for VPN-IPv6) The format of the END-POINTS object body for VPN-IPv4 is as follows: K.Kumaki, et al. [Page 5] draft-kumaki-murai-pce-pcep-extension-l3vpn-08 October 2011 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) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2 PCE Capabilities It is assumed that the BGP/MPLS IP-VPN ingress and egress PE routers have PCE capabilities. External PCE architectures will require further study and will be discussed in future revisions of this document. 3.2.1 PCReq Message Processing at Ingress PE (PCE) When an ingress PE (PCE) receives a PCReq message from a PCC/PCE, it can distinguish the VRF instance that is associated with an incoming interface: 1. The ingress PE processes the destination IPv4/IPv6 address in the END-POINTS object as the destination VPN-IPv4/VPN-IPv6 address for the VRF instance. K.Kumaki, et al. [Page 6] draft-kumaki-murai-pce-pcep-extension-l3vpn-08 October 2011 2. 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. 3. The destination VPN-IPv4/VPN-IPv6 address is then added to END-POINTS object consisting of the original destination IPv4/IPv6 address in END-POINTS object followed by the 8 octet 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. Also 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. 4. If necessary, the ingress PE will then send the PCReq message to next PCE (the egress PE for BGP/MPLS IP-VPNs). 5. Finally, the ingress PE should replace the incoming END-POINTS object from the PCC/PCE into the new END-POINTS object. 3.2.2 PCReq Message Processing at Egress PE (PCE) When an egress PE (PCE) receives a PCReq message from an ingress PE(PCE), it is able to distinguish the 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 (PE) if needed. The egress PE will then 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 egress PE should store the new END-POINTS object for a PCReq message in a VRF instance. 3.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 will 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 sends it to an ingress PE. 3.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 7] draft-kumaki-murai-pce-pcep-extension-l3vpn-08 October 2011 Therefore, it is now possible to generate a PCRep message to send to an appropriate PCC/PCE. 4. Security Considerations This document defines PCEP extensions for BGP/MPLS IP-VPNs. The security of the PCE extensions relies on the security of PCEP [RFC5440]. It is important that implementations conform to security features defined in [RFC5440]. 5. IANA Considerations IANA maintains a registry of PCEP parameters. As described in Section 3.1 (Type Definition), two Object-Types have been defined. IANA is requested to make the following allocations from the "PCEP Objects" sub-registry. Object-Class Name Object-Type Reference Value 4 END-POINTS 1: IPv4 addresses [RFC5440] 2: IPv6 addresses [RFC5440] 3: VPN-IPv4 addresses [This.I-D] 4: VPN-IPv6 addresses [This.I-D] 5-15: Unassigned The values 3 and 4 are suggested. 6. References 6.1 Normative References [RFC4271] Rekhter, Y. and Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC5440] Vasseur, J.-P., et al., "Path Computation Element(PCE) communication Protocol (PCEP) - Version 1", RFC5440, March 2009. K.Kumaki, et al. [Page 8] draft-kumaki-murai-pce-pcep-extension-l3vpn-08 October 2011 6.2 Informative References [RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "Path Computation Element (PCE) Architecture", RFC 4655, August 2006. [RFC5824] Kumaki, K., Zhang, R. and Kamite, Y., "Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN", RFC 5824, April 2010. [PCE-VPN-REQ] Yasukawa, S. and Farrel, A. "PCC-PCE Communication Requirements for VPNs", draft-ietf-pce-vpn-req, March 2011. [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- VPN ", draft-kumaki-pce-bgp-disco-attribute, September 2010. 7. Acknowledgments The author would like to express thanks to Makoto Nakamura for his helpful and useful comments and feedback. 8. Authors' Addresses Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Email: ke-kumaki@kddi.com Tomoki Murai FURUKAWA NETWORK SOLUTION CORP. 5-1-9, HIGASHI-YAWATA, HIRATSUKA Kanagawa 254-0016, JAPAN Email: murai@fnsc.co.jp K.Kumaki, et al. [Page 9] draft-kumaki-murai-pce-pcep-extension-l3vpn-08 October 2011 Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka, 560008, INDIA Email: dhruv.dhody@huawei.com Peng Jiang KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, JAPAN Email: pe-jiang@kddilabs.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