L3VPN K. Kompella Internet-Draft R. Bonica Expires: December 4, 2006 K. Yamashita Juniper Networks K. Kumaki KDDI Corporation June 2, 2006 Delivering MPLS Services Over L3VPN draft-bonica-mplsvpn-00 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 December 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes procedures that can be used to deliver MPLS services over Layer 3 Virtual Private Networks (L3VPN). Using these procedures, a VPN customer can signal MPLS Label Switched Paths (LSP) from Customer Edge (CE) router to CE router. Although a Service Provider (SP) network carries the Customer LSP (C-LSP) from one CE Kompella, et al. Expires December 4, 2006 [Page 1] Internet-Draft MPLS over L3VPN June 2006 router to another, the C-LSP does not interact with the SP network's routing or signaling infrastructure. Table of Contents 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Concept of Operation . . . . . . . . . . . . . . . . . . . . . 4 3.1. CE Routers Establish A Labeled Path Between One Another . 5 3.2. Customer Sites Exchange Internal Routes With One Another . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Signaling The C-LSP . . . . . . . . . . . . . . . . . . . 7 3.4. Traffic Engineering Considerations . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Kompella, et al. Expires December 4, 2006 [Page 2] Internet-Draft MPLS over L3VPN June 2006 1. Conventions Used In This Document In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119 [1]. 2. Introduction This document describes procedures that can be used to deliver MPLS [2] services over Layer 3 Virtual Private Networks. Reference [3] describes service requirements. Customer LSP's (C-LSP) ------------------------------------------------------------) (---------------------------------------------- Service Provider LSP (SP-LSP) ---------------------------) (--------------------------- ........... ........... . -- ---. --- --- --- --- .--- -- . .|C0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|----|CE2| |C3|. . -- ---. --- --- --- --- . --- -- . .......... ........... ^ ^ | | vrf instance vrf instance --Customer-- ------Service Provider-------- --Customer-- VPN Site A L3VPN VPN Site B Figure 1: Reference Model Figure 1 provides a reference model. In the figure, an SP maintains an L3VPN using BGP/MPLS technology [4]. The SP network contains two edge routers (PE1 and PE2) and two core routers (P1 and P2). All four SP routers participate in an IGP and a pair of unidirectional MPLS LSPs provide connectivity between PE1 and PE2. Because these LSPs are contained entirely by the SP network, we call them SP-LSPs. PE1 and PE2 also exchange customer routes with one another through a multiprotocol iBGP [5] session. Kompella, et al. Expires December 4, 2006 [Page 3] Internet-Draft MPLS over L3VPN June 2006 A VPN customer maintains one site at either end of the SP network. From VPN Site A, the customer attaches CE1 to PE1. From VPN Site B, the customer attaches CE2 to PE2. C0 resides VPN Site A and C3 resides in VPN Site B. This document describes procedures that allow the customer to establish RSVP-TE [6] signaled LSPs between VPN sites. Because these LSPs originate on one customer router and terminate on another, we call them Customer LSPs (C-LSP). A C-LSP can connect any router in one VPN site to any router in another VPN site. For example, a C-LSP might connect CE1 to CE2 or C0 to C3. The solution described herein is constrained by the service provider's business policy. The following constraints are applied: o The SP provides Layer 3 services only. It does not provide L2 services. o The SP provides VPN services only. The SP must carry all customer routes in a Virtual Routing and Forwarding (VRF) instance that is dedicated to the customer's VPN. The SP must not carry any customer routes in its general routing instance. o Customer routers must not participate in the Service Provider's IGP. o Customer routers must not exchange RSVP or LDP [10] messages with SP routers. 3. Concept of Operation The procedure described herein permits the customer to establish and maintain C-LSPs. Each C-LSP contains one or more hops, which for the purposes of this document, will be called C-hops. Each C-hop MUST originate on one customer router and terminate on another customer router. An C-hop MUST neither originate nor terminate on an SP router. So, returning to Figure 1, a C-LSP that connects C0 to C3 might include the following C-hops: o C0-CE1 Kompella, et al. Expires December 4, 2006 [Page 4] Internet-Draft MPLS over L3VPN June 2006 o CE1-CE2 o CE2-C3 Therefore, all MPLS state associated with an C-LSP is maintained on customer routers. This facilitates service scaling and precludes various kinds of DoS attacks against the SP. The salient characteristic of this solution is that one hop, connecting CE1 to CE2, spans the entire SP network. Note, however, that routers CE1 and CE2 are not adjacent to one another at Layer 3. So, the customer and SP must co-operate in order to provided a labeled path between CE1 and CE2. From a forwarding perspective, all C-LSPs that connect VPN Site A to VPN Site B are multiplexed over the labeled path that connects CE1 to CE2. From a signaling perspective, RSVP treats this labeled path as a single hop. All RSVP messages sent from VPN Site A to VPN Site B will traverse that labeled path. SP routers forward those RSVP messages without examining or processing them. However, the customer routers (CE1 and CE2) will process these messages and establish C-LSP state as required. The solution described herein is presented in four parts. These are: o procedures required to establish a labeled path between CE routers o procedures required to distribute customer internal routes between VPN sites o procedures required to signal the C-LSP o traffic engineering considerations Each part is described in a dedicated subsection below. 3.1. CE Routers Establish A Labeled Path Between One Another In order to establish a labeled path between CE routers, the SP configures its network as it would if it were to provide an L3VPN carrier-of-carriers service. (See Section 9 of reference [4] for details.) First, the SP configures its network for a basic BGP/MPLS IP VPN service. This configuration includes the following steps: Kompella, et al. Expires December 4, 2006 [Page 5] Internet-Draft MPLS over L3VPN June 2006 o Enable an IGP on all SP routers. o Establish a full mesh of MPLS LSPs among all PE routers (i.e., SP-LSPs). o Configure the SP network so that PE routers can exchange customer routes with one another using multiprotocol iBGP. This can be achieved using either a full mesh of multiprotocol iBGP neighboring sessions or a route reflector [11] configuration. Next, the SP configures multiprotocol eBGP sessions between its PE routers and the customer's CE routers. The SP configures the following export policy on each of these multiprotocol eBGP neighboring sessions: o Set next-hop to self (i.e., the PE router's loopback address) o Advertise all routes learned from BGP and belonging to the appropriate VRF The SP also configures these multiprotocol eBGP sessions with a default import policy. The default import policy causes the PE routers to relay, but otherwise not process, two new BGP extended communities [7]. One of these extended communities, called the C-next-hop, represents the loopback address of the advertising CE router. The other extended community, called the Link Bandwidth Community, represents the reservable bandwidth that on the link that connects the PE router to the advertising CE router. Because these extended communities are transitive, the PE router relays them as the were received. The following sections describe how these new extended communities are used. 3.2. Customer Sites Exchange Internal Routes With One Another The customer begins this process by enabling an IGP on all interfaces that are internal to the VPN site. The customer also floods router loopback interfaces into the IGP. However, the customer does not enable the IGP on the PE/CE interface. Therefore, each VPN site maintains a unique IGP domain. Next, the VPN customer configures its side of the multiprotocol eBGP sessions described in Section 3.1. The customer configures the following export policy on each of these multiprotocol eBGP neighboring sessions: Kompella, et al. Expires December 4, 2006 [Page 6] Internet-Draft MPLS over L3VPN June 2006 o set label to EXPLICIT NULL o set next-hop to self (i.e., the CE router's loopback address) o append a new BGP extended community called the C-next-hop. The C-next-hop, like the next-hop attribute, is set to the router's loopback address. o optionally, append a new BGP extended community called the the Link Bandwidth Community. The Link Bandwidth Community represents the reservable bandwidth that on the link that connects the PE router to the advertising CE router (See Section 3.4 for details.) o advertise all directly connected and IGP-learned routes The customer also configures the following import policy on each of these multiprotocol eBGP neighboring sessions: o accept or reject each prefix as per local security policy o if the prefix is accepted and it includes the new BGP C-next-hop extended community, overwrite the BGP next-hop with the C-next-hop Finally, the customer configures the CE router so that injects all eBGP-learned routes into the IGP. When the CE router floods these routes into the IGP, it employs IGP traffic engineering extensions [8] [9] so that traffic engineering parameters will be available in Traffic Engineering Databases throughout the VPN site. Traffic engineering information is obtained from the BGP advertisement and local configuration. See Section 3.4 for details. Having completed this procedure, and returning to Figure 1, let us review routing from C0 to C3. C0 has an IGP route to C3 through CE1. CE1 has an BGP route to C3 with a BGP next-hop of CE2. CE1's best path to CE2 is through the labeled path that connects it to CE2. CE2 has an iGP route to C3. 3.3. Signaling The C-LSP The customer configures an C-LSP using RSVP-TE. For the purpose of example, let us return to Figure 1 and assume that the customer configures an C-LSP from C0 to C3. Assume also that no bandwidth is reserved for this LSP. (We will revisit traffic engineering considerations in Section 3.4). C0 determines that it has a route to C3 (through CE1) and that that route traverses an MPLS enabled interface. So, CO formats an RSVP PATH message and sends it to CE1. The RSVP PATH message contains an Kompella, et al. Expires December 4, 2006 [Page 7] Internet-Draft MPLS over L3VPN June 2006 incomplete Explicit Route Object (ERO) that includes only CE1. Because the RSVP PATH message arrives at CE1 unlabeled, CE1 detects that the packet includes an IP Router Alert Option and processes the message. So, CE1 updates the RSVP PATH message (adding CE2 to the ERO) and forwards it through the labeled path to CE2. The labeled path to CE2 passes through PE1, P1, P2 and PE2. However, because the RSVP message arrives at these routers with a non-zero MPLS label, these routers do not detect its IP Router Alert Option and do not process the message. However, PE2 swaps the MPLS label and forwards the RSVP message to CE2 with an EXPLICIT NULL label. CE2 detects that the packet includes an IP Router Alert Option and processes the message. Finally, CE2 updates the message and forwards it to C3. C3 returns an RSVP-TE RESV message via the same path, creating MPLS state along the way. 3.4. Traffic Engineering Considerations Customers can configure traffic engineering parameters in association with a C-LSP. Specifically, customers can specify a bandwidth reservation and a pre-emption priority for each C-LSP. If the customer associates a bandwidth reservation with a C-LSP, customer routers will calculate the best path through which the required bandwidth is available. The following paragraphs describe traffic engineering procedures. When a CE router advertises a prefix to the PE router, the CE router can specify a Link Bandwidth Community. The Link Bandwidth Community represents the reservable bandwidth on the CE-PE link. PE routers are configured so that they do not process the Link Bandwidth Community. However, because the community is transitive, PE routers relay the Link Bandwidth Community to the CE router at the distant end of the SP network The CE router at the distant end of the SP network compares the bandwidth specified by the Link Bandwidth Community with the bandwidth that is available on the link that connects it to the PE router. It then injects the route to the distant CE into its IGP, specifying the lesser of the two bandwidths as the bandwidth labeled path that connects the two CE routers to one another. The IGP floods this information throughout its domain, so that the lesser bandwidth appears in Traffic Engineering databases throughout the VPN site. Finally, the customer configures a C-LSP. Customer routers invoke standard traffic engineering procedures to calculate the best path Kompella, et al. Expires December 4, 2006 [Page 8] Internet-Draft MPLS over L3VPN June 2006 and pre-empt other LSPs if necessary. If the new LSP results in a bandwidth reservation across labeled path that connects CE routers to one another, the CE router repeats its advertisement with an updated Link Bandwidth Community. It is anticipated that in the future, customers will want to associate many other traffic engineering parameters with the labeled path between CE routers. New BGP communities will be defined to advertise those attributes and RSVP will also consider them in the process of path calculation. The Link Bandwidth Community is of an extended type. The value of the high-order octet of the Type Field is 0x00. The value of the low-order octet of the Type field for this community is 0x04. The value of the Global Administrator sub-field in the Value Field MUST represent the Autonomous System of the router that attaches the Link Bandwidth Community. The bandwidth of the link is expressed as 4 octets in IEEE floating point format, units being bytes per second. It is carried in the Local Administrator sub-field of the Value Field. 4. Security Considerations In order to maintain their security postures, the SP and the customer must constrain their interactions with one another. On the forwarding plane, both parties should accept labeled traffic through the PE/CE interface only if they have advertised that label. On the control plane, the PE and CE router should exchange BGP traffic only. They MUST NOT exchange RSVP signaling or participate in a common IGP. 5. IANA Considerations IANA will assign two new BGP Extended Communities. These are the Link Bandwidth community and the C-Next-hop Community. 6. Acknowledgments Thanks to Yakov Rekhter for his comments regarding this draft. 7. References Kompella, et al. Expires December 4, 2006 [Page 9] Internet-Draft MPLS over L3VPN June 2006 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [3] Kumaki, K., "Requirements for delivering MPLS Services Over L3VPN", draft-kumaki-l3vpn-e2e-rsvp-te-reqts-00 (work in progress), February 2006. [4] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [5] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [6] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [7] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [8] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [9] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. 7.2. Informative References [10] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [11] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. Kompella, et al. Expires December 4, 2006 [Page 10] Internet-Draft MPLS over L3VPN June 2006 Authors' Addresses Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA Email: kireeti@juniper.net Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA Email: rpb@juniper.net Koh Yamashita Juniper Networks 3-7-1 Nishi Shinjuku Shinjuku-Ku Tokyo, 163-1053 Japan Email: kohy@juniper.net Kenji Kumaki KDDI Corporation Garden Air Tower, Iidabashi Chiyoda-ku Tokyo, 102-8460 Japan Email: ke-kumaki@kddi.com Kompella, et al. Expires December 4, 2006 [Page 11] Internet-Draft MPLS over L3VPN June 2006 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 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 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 Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kompella, et al. Expires December 4, 2006 [Page 12]