diff options
Diffstat (limited to 'doc/rfc/rfc2547.txt')
| -rw-r--r-- | doc/rfc/rfc2547.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc2547.txt b/doc/rfc/rfc2547.txt new file mode 100644 index 0000000..f364dc9 --- /dev/null +++ b/doc/rfc/rfc2547.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group E. Rosen +Request for Comments: 2547 Y. Rekhter +Category: Informational Cisco Systems, Inc. + March 1999 + + + BGP/MPLS VPNs + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + This document describes a method by which a Service Provider with an + IP backbone may provide VPNs (Virtual Private Networks) for its + customers. MPLS (Multiprotocol Label Switching) is used for + forwarding packets over the backbone, and BGP (Border Gateway + Protocol) is used for distributing routes over the backbone. The + primary goal of this method is to support the outsourcing of IP + backbone services for enterprise networks. It does so in a manner + which is simple for the enterprise, while still scalable and flexible + for the Service Provider, and while allowing the Service Provider to + add value. These techniques can also be used to provide a VPN which + itself provides IP service to customers. + +Table of Contents + + 1 Introduction ....................................... 2 + 1.1 Virtual Private Networks ........................... 2 + 1.2 Edge Devices ....................................... 3 + 1.3 VPNs with Overlapping Address Spaces ............... 4 + 1.4 VPNs with Different Routes to the Same System ...... 4 + 1.5 Multiple Forwarding Tables in PEs .................. 5 + 1.6 SP Backbone Routers ................................ 5 + 1.7 Security ........................................... 5 + 2 Sites and CEs ...................................... 6 + 3 Per-Site Forwarding Tables in the PEs .............. 6 + 3.1 Virtual Sites ...................................... 8 + 4 VPN Route Distribution via BGP ..................... 8 + 4.1 The VPN-IPv4 Address Family ........................ 9 + 4.2 Controlling Route Distribution ..................... 10 + + + +Rosen & Rekhter Informational [Page 1] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + 4.2.1 The Target VPN Attribute ........................... 10 + 4.2.2 Route Distribution Among PEs by BGP ................ 12 + 4.2.3 The VPN of Origin Attribute ........................ 13 + 4.2.4 Building VPNs using Target and Origin Attributes ... 14 + 5 Forwarding Across the Backbone ..................... 15 + 6 How PEs Learn Routes from CEs ...................... 16 + 7 How CEs learn Routes from PEs ...................... 19 + 8 What if the CE Supports MPLS? ...................... 19 + 8.1 Virtual Sites ...................................... 19 + 8.2 Representing an ISP VPN as a Stub VPN .............. 20 + 9 Security ........................................... 20 + 9.1 Point-to-Point Security Tunnels between CE Routers . 21 + 9.2 Multi-Party Security Associations .................. 21 + 10 Quality of Service ................................. 22 + 11 Scalability ........................................ 22 + 12 Intellectual Property Considerations ............... 23 + 13 Security Considerations ............................ 23 + 14 Acknowledgments .................................... 23 + 15 Authors' Addresses ................................. 24 + 16 References ......................................... 24 + 17 Full Copyright Statement............................. 25 + +1. Introduction + +1.1. Virtual Private Networks + + Consider a set of "sites" which are attached to a common network + which we may call the "backbone". Let's apply some policy to create a + number of subsets of that set, and let's impose the following rule: + two sites may have IP interconnectivity over that backbone only if at + least one of these subsets contains them both. + + The subsets we have created are "Virtual Private Networks" (VPNs). + Two sites have IP connectivity over the common backbone only if there + is some VPN which contains them both. Two sites which have no VPN in + common have no connectivity over that backbone. + + If all the sites in a VPN are owned by the same enterprise, the VPN + is a corporate "intranet". If the various sites in a VPN are owned + by different enterprises, the VPN is an "extranet". A site can be in + more than one VPN; e.g., in an intranet and several extranets. We + regard both intranets and extranets as VPNs. In general, when we use + the term VPN we will not be distinguishing between intranets and + extranets. + + We wish to consider the case in which the backbone is owned and + operated by one or more Service Providers (SPs). The owners of the + sites are the "customers" of the SPs. The policies that determine + + + +Rosen & Rekhter Informational [Page 2] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + whether a particular collection of sites is a VPN are the policies of + the customers. Some customers will want the implementation of these + policies to be entirely the responsibility of the SP. Other + customers may want to implement these policies themselves, or to + share with the SP the responsibility for implementing these policies. + In this document, we are primarily discussing mechanisms that may be + used to implement these policies. The mechanisms we describe are + general enough to allow these policies to be implemented either by + the SP alone, or by a VPN customer together with the SP. Most of the + discussion is focused on the former case, however. + + The mechanisms discussed in this document allow the implementation of + a wide range of policies. For example, within a given VPN, we can + allow every site to have a direct route to every other site ("full + mesh"), or we can restrict certain pairs of sites from having direct + routes to each other ("partial mesh"). + + In this document, we are particularly interested in the case where + the common backbone offers an IP service. We are primarily concerned + with the case in which an enterprise is outsourcing its backbone to a + service provider, or perhaps to a set of service providers, with + which it maintains contractual relationships. We are not focused on + providing VPNs over the public Internet. + + In the rest of this introduction, we specify some properties which + VPNs should have. The remainder of this document outlines a VPN + model which has all these properties. The VPN Model of this document + appears to be an instance of the framework described in [4]. + +1.2. Edge Devices + + We suppose that at each site, there are one or more Customer Edge + (CE) devices, each of which is attached via some sort of data link + (e.g., PPP, ATM, ethernet, Frame Relay, GRE tunnel, etc.) to one or + more Provider Edge (PE) routers. + + If a particular site has a single host, that host may be the CE + device. If a particular site has a single subnet, that the CE device + may be a switch. In general, the CE device can be expected to be a + router, which we call the CE router. + + We will say that a PE router is attached to a particular VPN if it is + attached to a CE device which is in that VPN. Similarly, we will say + that a PE router is attached to a particular site if it is attached + to a CE device which is in that site. + + When the CE device is a router, it is a routing peer of the PE(s) to + which it is attached, but is not a routing peer of CE routers at + + + +Rosen & Rekhter Informational [Page 3] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + other sites. Routers at different sites do not directly exchange + routing information with each other; in fact, they do not even need + to know of each other at all (except in the case where this is + necessary for security purposes, see section 9). As a consequence, + very large VPNs (i.e., VPNs with a very large number of sites) are + easily supported, while the routing strategy for each individual site + is greatly simplified. + + It is important to maintain clear administrative boundaries between + the SP and its customers (cf. [4]). The PE and P routers should be + administered solely by the SP, and the SP's customers should not have + any management access to it. The CE devices should be administered + solely by the customer (unless the customer has contracted the + management services out to the SP). + +1.3. VPNs with Overlapping Address Spaces + + We assume that any two non-intersecting VPNs (i.e., VPNs with no + sites in common) may have overlapping address spaces; the same + address may be reused, for different systems, in different VPNs. As + long as a given endsystem has an address which is unique within the + scope of the VPNs that it belongs to, the endsystem itself does not + need to know anything about VPNs. + + In this model, the VPN owners do not have a backbone to administer, + not even a "virtual backbone". Nor do the SPs have to administer a + separate backbone or "virtual backbone" for each VPN. Site-to-site + routing in the backbone is optimal (within the constraints of the + policies used to form the VPNs), and is not constrained in any way by + an artificial "virtual topology" of tunnels. + +1.4. VPNs with Different Routes to the Same System + + Although a site may be in multiple VPNs, it is not necessarily the + case that the route to a given system at that site should be the same + in all the VPNs. Suppose, for example, we have an intranet + consisting of sites A, B, and C, and an extranet consisting of A, B, + C, and the "foreign" site D. Suppose that at site A there is a + server, and we want clients from B, C, or D to be able to use that + server. Suppose also that at site B there is a firewall. We want + all the traffic from site D to the server to pass through the + firewall, so that traffic from the extranet can be access controlled. + However, we don't want traffic from C to pass through the firewall on + the way to the server, since this is intranet traffic. + + This means that it needs to be possible to set up two routes to the + server. One route, used by sites B and C, takes the traffic directly + to site A. The second route, used by site D, takes the traffic + + + +Rosen & Rekhter Informational [Page 4] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + instead to the firewall at site B. If the firewall allows the + traffic to pass, it then appears to be traffic coming from site B, + and follows the route to site A. + +1.5. Multiple Forwarding Tables in PEs + + Each PE router needs to maintain a number of separate forwarding + tables. Every site to which the PE is attached must be mapped to one + of those forwarding tables. When a packet is received from a + particular site, the forwarding table associated with that site is + consulted in order to determine how to route the packet. The + forwarding table associated with a particular site S is populated + only with routes that lead to other sites which have at least one VPN + in common with S. This prevents communication between sites which + have no VPN in common, and it allows two VPNs with no site in common + to use address spaces that overlap with each other. + +1.6. SP Backbone Routers + + The SP's backbone consists of the PE routers, as well as other + routers (P routers) which do not attach to CE devices. + + If every router in an SP's backbone had to maintain routing + information for all the VPNs supported by the SP, this model would + have severe scalability problems; the number of sites that could be + supported would be limited by the amount of routing information that + could be held in a single router. It is important to require + therefore that the routing information about a particular VPN be + present ONLY in those PE routers which attach to that VPN. In + particular, the P routers should not need to have ANY per-VPN routing + information whatsoever. + + VPNs may span multiple service providers. We assume though that when + the path between PE routers crosses a boundary between SP networks, + it does so via a private peering arrangement, at which there exists + mutual trust between the two providers. In particular, each provider + must trust the other to pass it only correct routing information, and + to pass it labeled (in the sense of MPLS [9]) packets only if those + packets have been labeled by trusted sources. We also assume that it + is possible for label switched paths to cross the boundary between + service providers. + +1.7. Security + + A VPN model should, even without the use of cryptographic security + measures, provide a level of security equivalent to that obtainable + when a level 2 backbone (e.g., Frame Relay) is used. That is, in the + absence of misconfiguration or deliberate interconnection of + + + +Rosen & Rekhter Informational [Page 5] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + different VPNs, it should not be possible for systems in one VPN to + gain access to systems in another VPN. + + It should also be possible to deploy standard security procedures. + +2. Sites and CEs + + From the perspective of a particular backbone network, a set of IP + systems constitutes a site if those systems have mutual IP + interconnectivity, and communication between them occurs without use + of the backbone. In general, a site will consist of a set of systems + which are in geographic proximity. However, this is not universally + true; two geographic locations connected via a leased line, over + which OSPF is running, will constitute a single site, because + communication between the two locations does not involve the use of + the backbone. + + A CE device is always regarded as being in a single site (though as + we shall see, a site may consist of multiple "virtual sites"). A + site, however, may belong to multiple VPNs. + + A PE router may attach to CE devices in any number of different + sites, whether those CE devices are in the same or in different VPNs. + A CE device may, for robustness, attach to multiple PE routers, of + the same or of different service providers. If the CE device is a + router, the PE router and the CE router will appear as router + adjacencies to each other. + + While the basic unit of interconnection is the site, the architecture + described herein allows a finer degree of granularity in the control + of interconnectivity. For example, certain systems at a site may be + members of an intranet as well as members of one or more extranets, + while other systems at the same site may be restricted to being + members of the intranet only. + +3. Per-Site Forwarding Tables in the PEs + + Each PE router maintains one or more "per-site forwarding tables". + Every site to which the PE router is attached is associated with one + of these tables. A particular packet's IP destination address is + looked up in a particular per-site forwarding table only if that + packet has arrived directly from a site which is associated with that + table. + + How are the per-site forwarding tables populated? + + + + + + +Rosen & Rekhter Informational [Page 6] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + As an example, let PE1, PE2, and PE3 be three PE routers, and let + CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from + CE1, the routes which are reachable at CE1's site. If PE2 and PE3 + are attached respectively to CE2 and CE3, and there is some VPN V + containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2 + and PE3 the routes which it has learned from CE1. PE2 and PE3 use + these routes to populate the forwarding tables which they associate + respectively with the sites of CE2 and CE3. Routes from sites which + are not in VPN V do not appear in these forwarding tables, which + means that packets from CE2 or CE3 cannot be sent to sites which are + not in VPN V. + + If a site is in multiple VPNs, the forwarding table associated with + that site can contain routes from the full set of VPNs of which the + site is a member. + + A PE generally maintains only one forwarding table per site, even if + it is multiply connected to that site. Also, different sites can + share the same forwarding table if they are meant to use exactly the + same set of routes. + + Suppose a packet is received by a PE router from a particular + directly attached site, but the packet's destination address does not + match any entry in the forwarding table associated with that site. + If the SP is not providing Internet access for that site, then the + packet is discarded as undeliverable. If the SP is providing + Internet access for that site, then the PE's Internet forwarding + table will be consulted. This means that in general, only one + forwarding table per PE need ever contain routes from the Internet, + even if Internet access is provided. + + To maintain proper isolation of one VPN from another, it is important + that no router in the backbone accept a labeled packet from any + adjacent non-backbone device unless (a) the label at the top of the + label stack was actually distributed by the backbone router to the + non-backbone device, and (b) the backbone router can determine that + use of that label will cause the packet to leave the backbone before + any labels lower in the stack will be inspected, and before the IP + header will be inspected. These restrictions are necessary in order + to prevent packets from entering a VPN where they do not belong. + + The per-site forwarding tables in a PE are ONLY used for packets + which arrive from a site which is directly attached to the PE. They + are not used for routing packets which arrive from other routers that + belong to the SP backbone. As a result, there may be multiple + different routes to the same system, where the route followed by a + given packet is determined by the site from which the packet enters + the backbone. E.g., one may have one route to a given system for + + + +Rosen & Rekhter Informational [Page 7] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + packets from the extranet (where the route leads to a firewall), and + a different route to the same system for packets from the intranet + (including packets that have already passed through the firewall). + +3.1. Virtual Sites + + In some cases, a particular site may be divided by the customer into + several virtual sites, perhaps by the use of VLANs. Each virtual + site may be a member of a different set of VPNs. The PE then needs to + contain a separate forwarding table for each virtual site. For + example, if a CE supports VLANs, and wants each VLAN mapped to a + separate VPN, the packets sent between CE and PE could be contained + in the site's VLAN encapsulation, and this could be used by the PE, + along with the interface over which the packet is received, to assign + the packet to a particular virtual site. + + Alternatively, one could divide the interface into multiple "sub- + interfaces" (particularly if the interface is Frame Relay or ATM), + and assign the packet to a VPN based on the sub-interface over which + it arrives. Or one could simply use a different interface for each + virtual site. In any case, only one CE router is ever needed per + site, even if there are multiple virtual sites. Of course, a + different CE router could be used for each virtual site, if that is + desired. + + Note that in all these cases, the mechanisms, as well as the policy, + for controlling which traffic is in which VPN are in the hand of the + customer. + + If it is desired to have a particular host be in multiple virtual + sites, then that host must determine, for each packet, which virtual + site the packet is associated with. It can do this, e.g., by sending + packets from different virtual sites on different VLANs, our out + different network interfaces. + + These schemes do NOT require the CE to support MPLS. Section 8 + contains a brief discussion of how the CE might support multiple + virtual sites if it does support MPLS. + +4. VPN Route Distribution via BGP + + PE routers use BGP to distribute VPN routes to each other (more + accurately, to cause VPN routes to be distributed to each other). + + A BGP speaker can only install and distribute one route to a given + address prefix. Yet we allow each VPN to have its own address space, + which means that the same address can be used in any number of VPNs, + where in each VPN the address denotes a different system. It follows + + + +Rosen & Rekhter Informational [Page 8] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + that we need to allow BGP to install and distribute multiple routes + to a single IP address prefix. Further, we must ensure that POLICY + is used to determine which sites can be use which routes; given that + several such routes are installed by BGP, only one such must appear + in any particular per-site forwarding table. + + We meet these goals by the use of a new address family, as specified + below. + +4.1. The VPN-IPv4 Address Family + + The BGP Multiprotocol Extensions [3] allow BGP to carry routes from + multiple "address families". We introduce the notion of the "VPN- + IPv4 address family". A VPN-IPv4 address is a 12-byte quantity, + beginning with an 8-byte "Route Distinguisher (RD)" and ending with a + 4-byte IPv4 address. If two VPNs use the same IPv4 address prefix, + the PEs translate these into unique VPN-IPv4 address prefixes. This + ensures that if the same address is used in two different VPNs, it is + possible to install two completely different routes to that address, + one for each VPN. + + The RD does not by itself impose any semantics; it contains no + information about the origin of the route or about the set of VPNs to + which the route is to be distributed. The purpose of the RD is + solely to allow one to create distinct routes to a common IPv4 + address prefix. Other means are used to determine where to + redistribute the route (see section 4.2). + + The RD can also be used to create multiple different routes to the + very same system. In section 3, we gave an example where the route + to a particular server had to be different for intranet traffic than + for extranet traffic. This can be achieved by creating two different + VPN-IPv4 routes that have the same IPv4 part, but different RDs. + This allows BGP to install multiple different routes to the same + system, and allows policy to be used (see section 4.2.3) to decide + which packets use which route. + + The RDs are structured so that every service provider can administer + its own "numbering space" (i.e., can make its own assignments of + RDs), without conflicting with the RD assignments made by any other + service provider. An RD consists of a two-byte type field, an + administrator field, and an assigned number field. The value of the + type field determines the lengths of the other two fields, as well as + the semantics of the administrator field. The administrator field + identifies an assigned number authority, and the assigned number + field contains a number which has been assigned, by the identified + authority, for a particular purpose. For example, one could have an + RD whose administrator field contains an Autonomous System number + + + +Rosen & Rekhter Informational [Page 9] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + (ASN), and whose (4-byte) number field contains a number assigned by + the SP to whom IANA has assigned that ASN. RDs are given this + structure in order to ensure that an SP which provides VPN backbone + service can always create a unique RD when it needs to do so. + However, the structuring provides no semantics. When BGP compares two + such address prefixes, it ignores the structure entirely. + + If the Administrator subfield and the Assigned Number subfield of a + VPN-IPv4 address are both set to all zeroes, the VPN-IPv4 address is + considered to have exactly the same meaning as the corresponding + globally unique IPv4 address. In particular, this VPN-IPv4 address + and the corresponding globally unique IPv4 address will be considered + comparable by BGP. In all other cases, a VPN-IPv4 address and its + corresponding globally unique IPv4 address will be considered + noncomparable by BGP. + + A given per-site forwarding table will only have one VPN-IPv4 route + for any given IPv4 address prefix. When a packet's destination + address is matched against a VPN-IPv4 route, only the IPv4 part is + actually matched. + + A PE needs to be configured to associate routes which lead to + particular CE with a particular RD. The PE may be configured to + associate all routes leading to the same CE with the same RD, or it + may be configured to associate different routes with different RDs, + even if they lead to the same CE. + +4.2. Controlling Route Distribution + + In this section, we discuss the way in which the distribution of the + VPN-IPv4 routes is controlled. + +4.2.1. The Target VPN Attribute + + Every per-site forwarding table is associated with one or more + "Target VPN" attributes. + + When a VPN-IPv4 route is created by a PE router, it is associated + with one or more "Target VPN" attributes. These are carried in BGP + as attributes of the route. + + Any route associated with Target VPN T must be distributed to every + PE router that has a forwarding table associated with Target VPN T. + When such a route is received by a PE router, it is eligible to be + installed in each of the PE's per-site forwarding tables that is + associated with Target VPN T. (Whether it actually gets installed + depends on the outcome of the BGP decision process.) + + + + +Rosen & Rekhter Informational [Page 10] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + In essence, a Target VPN attribute identifies a set of sites. + Associating a particular Target VPN attribute with a route allows + that route to be placed in the per-site forwarding tables that are + used for routing traffic which is received from the corresponding + sites. + + There is a set of Target VPNs that a PE router attaches to a route + received from site S. And there is a set of Target VPNs that a PE + router uses to determine whether a route received from another PE + router could be placed in the forwarding table associated with site + S. The two sets are distinct, and need not be the same. + + The function performed by the Target VPN attribute is similar to that + performed by the BGP Communities Attribute. However, the format of + the latter is inadequate, since it allows only a two-byte numbering + space. It would be fairly straightforward to extend the BGP + Communities Attribute to provide a larger numbering space. It should + also be possible to structure the format, similar to what we have + described for RDs (see section 4.1), so that a type field defines the + length of an administrator field, and the remainder of the attribute + is a number from the specified administrator's numbering space. + + When a BGP speaker has received two routes to the same VPN-IPv4 + prefix, it chooses one, according to the BGP rules for route + preference. + + Note that a route can only have one RD, but it can have multiple + Target VPNs. In BGP, scalability is improved if one has a single + route with multiple attributes, as opposed to multiple routes. One + could eliminate the Target VPN attribute by creating more routes + (i.e., using more RDs), but the scaling properties would be less + favorable. + + How does a PE determine which Target VPN attributes to associate with + a given route? There are a number of different possible ways. The + PE might be configured to associate all routes that lead to a + particular site with a particular Target VPN. Or the PE might be + configured to associate certain routes leading to a particular site + with one Target VPN, and certain with another. Or the CE router, + when it distributes these routes to the PE (see section 6), might + specify one or more Target VPNs for each route. The latter method + shifts the control of the mechanisms used to implement the VPN + policies from the SP to the customer. If this method is used, it may + still be desirable to have the PE eliminate any Target VPNs that, + according to its own configuration, are not allowed, and/or to add in + some Target VPNs that according to its own configuration are + mandatory. + + + + +Rosen & Rekhter Informational [Page 11] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + It might be more accurate, if less suggestive, to call this attribute + the "Route Target" attribute instead of the "VPN Target" attribute. + It really identifies only a set of sites which will be able to use + the route, without prejudice to whether those sites constitute what + might intuitively be called a VPN. + +4.2.2. Route Distribution Among PEs by BGP + + If two sites of a VPN attach to PEs which are in the same Autonomous + System, the PEs can distribute VPN-IPv4 routes to each other by means + of an IBGP connection between them. Alternatively, each can have an + IBGP connection to a route reflector. + + If two sites of VPN are in different Autonomous Systems (e.g., + because they are connected to different SPs), then a PE router will + need to use IBGP to redistribute VPN-IPv4 routes either to an + Autonomous System Border Router (ASBR), or to a route reflector of + which an ASBR is a client. The ASBR will then need to use EBGP to + redistribute those routes to an ASBR in another AS. This allows one + to connect different VPN sites to different Service Providers. + However, VPN-IPv4 routes should only be accepted on EBGP connections + at private peering points, as part of a trusted arrangement between + SPs. VPN-IPv4 routes should neither be distributed to nor accepted + from the public Internet. + + If there are many VPNs having sites attached to different Autonomous + Systems, there does not need to be a single ASBR between those two + ASes which holds all the routes for all the VPNs; there can be + multiple ASBRs, each of which holds only the routes for a particular + subset of the VPNs. + + When a PE router distributes a VPN-IPv4 route via BGP, it uses its + own address as the "BGP next hop". It also assigns and distributes + an MPLS label. (Essentially, PE routers distribute not VPN-IPv4 + routes, but Labeled VPN-IPv4 routes. Cf. [8]) When the PE processes a + received packet that has this label at the top of the stack, the PE + will pop the stack, and send the packet directly to the site from to + which the route leads. This will usually mean that it just sends the + packet to the CE router from which it learned the route. The label + may also determine the data link encapsulation. + + In most cases, the label assigned by a PE will cause the packet to be + sent directly to a CE, and the PE which receives the labeled packet + will not look up the packet's destination address in any forwarding + table. However, it is also possible for the PE to assign a label + which implicitly identifies a particular forwarding table. In this + case, the PE receiving a packet that label would look up the packet's + destination address in one of its forwarding tables. While this can + + + +Rosen & Rekhter Informational [Page 12] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + be very useful in certain circumstances, we do not consider it + further in this paper. + + Note that the MPLS label that is distributed in this way is only + usable if there is a label switched path between the router that + installs a route and the BGP next hop of that route. We do not make + any assumption about the procedure used to set up that label switched + path. It may be set up on a pre-established basis, or it may be set + up when a route which would need it is installed. It may be a "best + effort" route, or it may be a traffic engineered route. Between a + particular PE router and its BGP next hop for a particular route + there may be one LSP, or there may be several, perhaps with different + QoS characteristics. All that matters for the VPN architecture is + that some label switched path between the router and its BGP next hop + exists. + + All the usual techniques for using route reflectors [2] to improve + scalability, e.g., route reflector hierarchies, are available. If + route reflectors are used, there is no need to have any one route + reflector know all the VPN-IPv4 routes for all the VPNs supported by + the backbone. One can have separate route reflectors, which do not + communicate with each other, each of which supports a subset of the + total set of VPNs. + + If a given PE router is not attached to any of the Target VPNs of a + particular route, it should not receive that route; the other PE or + route reflector which is distributing routes to it should apply + outbound filtering to avoid sending it unnecessary routes. Of + course, if a PE router receives a route via BGP, and that PE is not + attached to any of the route's target VPNs, the PE should apply + inbound filtering to the route, neither installing nor redistributing + it. + + A router which is not attached to any VPN, i.e., a P router, never + installs any VPN-IPv4 routes at all. + + These distribution rules ensure that there is no one box which needs + to know all the VPN-IPv4 routes that are supported over the backbone. + As a result, the total number of such routes that can be supported + over the backbone is not bound by the capacity of any single device, + and therefore can increase virtually without bound. + +4.2.3. The VPN of Origin Attribute + + A VPN-IPv4 route may be optionally associated with a VPN of Origin + attribute. This attribute uniquely identifies a set of sites, and + identifies the corresponding route as having come from one of the + sites in that set. Typical uses of this attribute might be to + + + +Rosen & Rekhter Informational [Page 13] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + identify the enterprise which owns the site where the route leads, or + to identify the site's intranet. However, other uses are also + possible. This attribute could be encoded as an extended BGP + communities attribute. + + In situations in which it is necessary to identify the source of a + route, it is this attribute, not the RD, which must be used. This + attribute may be used when "constructing" VPNs, as described below. + + It might be more accurate, if less suggestive, to call this attribute + the "Route Origin" attribute instead of the "VPN of Origin" + attribute. It really identifies the route only has having come from + one of a particular set of sites, without prejudice as to whether + that particular set of sites really constitutes a VPN. + +4.2.4. Building VPNs using Target and Origin Attributes + + By setting up the Target VPN and VPN of Origin attributes properly, + one can construct different kinds of VPNs. + + Suppose it is desired to create a Closed User Group (CUG) which + contains a particular set of sites. This can be done by creating a + particular Target VPN attribute value to represent the CUG. This + value then needs to be associated with the per-site forwarding tables + for each site in the CUG, and it needs to be associated with every + route learned from a site in the CUG. Any route which has this + Target VPN attribute will need to be redistributed so that it reaches + every PE router attached to one of the sites in the CUG. + + Alternatively, suppose one desired, for whatever reason, to create a + "hub and spoke" kind of VPN. This could be done by the use of two + Target Attribute values, one meaning "Hub" and one meaning "Spoke". + Then routes from the spokes could be distributed to the hub, without + causing routes from the hub to be distributed to the spokes. + + Suppose one has a number of sites which are in an intranet and an + extranet, as well as a number of sites which are in the intranet + only. Then there may be both intranet and extranet routes which have + a Target VPN identifying the entire set of sites. The sites which + are to have intranet routes only can filter out all routes with the + "wrong" VPN of Origin. + + These two attributes allow great flexibility in allowing one to + control the distribution of routing information among various sets of + sites, which in turn provides great flexibility in constructing VPNs. + + + + + + +Rosen & Rekhter Informational [Page 14] + +RFC 2547 BGP/MPLS VPNs March 1999 + + +5. Forwarding Across the Backbone + + If the intermediate routes in the backbone do not have any + information about the routes to the VPNs, how are packets forwarded + from one VPN site to another? + + This is done by means of MPLS with a two-level label stack. + + PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to + insert /32 address prefixes for themselves into the IGP routing + tables of the backbone. This enables MPLS, at each node in the + backbone network, to assign a label corresponding to the route to + each PE router. (Certain procedures for setting up label switched + paths in the backbone may not require the presence of the /32 address + prefixes.) + + When a PE receives a packet from a CE device, it chooses a particular + per-site forwarding table in which to look up the packet's + destination address. Assume that a match is found. + + If the packet is destined for a CE device attached to this same PE, + the packet is sent directly to that CE device. + + If the packet is not destined for a CE device attached to this same + PE, the packet's "BGP Next Hop" is found, as well as the label which + that BGP next hop assigned for the packet's destination address. This + label is pushed onto the packet's label stack, and becomes the bottom + label. Then the PE looks up the IGP route to the BGP Next Hop, and + thus determines the IGP next hop, as well as the label assigned to + the address of the BGP next hop by the IGP next hop. This label gets + pushed on as the packet's top label, and the packet is then forwarded + to the IGP next hop. (If the BGP next hop is the same as the IGP + next hop, the second label may not need to be pushed on, however.) + + At this point, MPLS will carry the packet across the backbone and + into the appropriate CE device. That is, all forwarding decisions by + P routers and PE routers are now made by means of MPLS, and the + packet's IP header is not looked at again until the packet reaches + the CE device. The final PE router will pop the last label from the + MPLS label stack before sending the packet to the CE device, thus the + CE device will just see an ordinary IP packet. (Though see section 8 + for some discussion of the case where the CE desires to received + labeled packets.) + + When a packet enters the backbone from a particular site via a + particular PE router, the packet's route is determined by the + contents of the forwarding table which that PE router associated with + that site. The forwarding tables of the PE router where the packet + + + +Rosen & Rekhter Informational [Page 15] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + leaves the backbone are not relevant. As a result, one may have + multiple routes to the same system, where the particular route chosen + for a particular packet is based on the site from which the packet + enters the backbone. + + Note that it is the two-level labeling that makes it possible to keep + all the VPN routes out of the P routers, and this in turn is crucial + to ensuring the scalability of the model. The backbone does not even + need to have routes to the CEs, only to the PEs. + +6. How PEs Learn Routes from CEs + + The PE routers which attach to a particular VPN need to know, for + each of that VPN's sites, which addresses in that VPN are at each + site. + + In the case where the CE device is a host or a switch, this set of + addresses will generally be configured into the PE router attaching + to that device. In the case where the CE device is a router, there + are a number of possible ways that a PE router can obtain this set of + addresses. + + The PE translates these addresses into VPN-IPv4 addresses, using a + configured RD. The PE then treats these VPN-IPv4 routes as input to + BGP. In no case will routes from a site ever be leaked into the + backbone's IGP. + + Exactly which PE/CE route distribution techniques are possible + depends on whether a particular CE is in a "transit VPN" or not. A + "transit VPN" is one which contains a router that receives routes + from a "third party" (i.e., from a router which is not in the VPN, + but is not a PE router), and that redistributes those routes to a PE + router. A VPN which is not a transit VPN is a "stub VPN". The vast + majority of VPNs, including just about all corporate enterprise + networks, would be expected to be "stubs" in this sense. + + The possible PE/CE distribution techniques are: + + 1. Static routing (i.e., configuration) may be used. (This is + likely to be useful only in stub VPNs.) + + 2. PE and CE routers may be RIP peers, and the CE may use RIP to + tell the PE router the set of address prefixes which are + reachable at the CE router's site. When RIP is configured in + the CE, care must be taken to ensure that address prefixes from + other sites (i.e., address prefixes learned by the CE router + from the PE router) are never advertised to the PE. More + precisely: if a PE router, say PE1, receives a VPN-IPv4 route + + + +Rosen & Rekhter Informational [Page 16] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + R1, and as a result distributes an IPv4 route R2 to a CE, then + R2 must not be distributed back from that CE's site to a PE + router, say PE2, (where PE1 and PE2 may be the same router or + different routers), unless PE2 maps R2 to a VPN-IPv4 route + which is different than (i.e., contains a different RD than) + R1. + + 3. The PE and CE routers may be OSPF peers. In this case, the + site should be a single OSPF area, the CE should be an ABR in + that area, and the PE should be an ABR which is not in that + area. Also, the PE should report no router links other than + those to the CEs which are at the same site. (This technique + should be used only in stub VPNs.) + + 4. The PE and CE routers may be BGP peers, and the CE router may + use BGP (in particular, EBGP to tell the PE router the set of + address prefixes which are at the CE router's site. (This + technique can be used in stub VPNs or transit VPNs.) + + From a purely technical perspective, this is by far the best + technique: + + a) Unlike the IGP alternatives, this does not require the + PE to run multiple routing algorithm instances in order + to talk to multiple CEs + + b) BGP is explicitly designed for just this function: + passing routing information between systems run by + different administrations + + c) If the site contains "BGP backdoors", i.e., routers + with BGP connections to routers other than PE routers, + this procedure will work correctly in all + circumstances. The other procedures may or may not + work, depending on the precise circumstances. + + d) Use of BGP makes it easy for the CE to pass attributes + of the routes to the PE. For example, the CE may + suggest a particular Target for each route, from among + the Target attributes that the PE is authorized to + attach to the route. + + On the other hand, using BGP is likely to be something new for + the CE administrators, except in the case where the customer + itself is already an Internet Service Provider (ISP). + + + + + + +Rosen & Rekhter Informational [Page 17] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + If a site is not in a transit VPN, note that it need not have + a unique Autonomous System Number (ASN). Every CE whose site + which is not in a transit VPN can use the same ASN. This can + be chosen from the private ASN space, and it will be stripped + out by the PE. Routing loops are prevented by use of the Site + of Origin Attribute (see below). + + If a set of sites constitute a transit VPN, it is convenient + to represent them as a BGP Confederation, so that the internal + structure of the VPN is hidden from any router which is not + within the VPN. In this case, each site in the VPN would need + two BGP connections to the backbone, one which is internal to + the confederation and one which is external to it. The usual + intra-confederation procedures would have to be slightly + modified in order to take account for the fact that the + backbone and the sites may have different policies. The + backbone is a member of the confederation on one of the + connections, but is not a member on the other. These + techniques may be useful if the customer for the VPN service + is an ISP. This technique allows a customer that is an ISP to + obtain VPN backbone service from one of its ISP peers. + + (However, if a VPN customer is itself an ISP, and its CE + routers support MPLS, a much simpler technique can be used, + wherein the ISP is regarded as a stub VPN. See section 8.) + + When we do not need to distinguish among the different ways in which + a PE can be informed of the address prefixes which exist at a given + site, we will simply say that the PE has "learned" the routes from + that site. + + Before a PE can redistribute a VPN-IPv4 route learned from a site, it + must assign certain attributes to the route. There are three such + attributes: + + - Site of Origin + + This attribute uniquely identifies the site from which the PE + router learned the route. All routes learned from a particular + site must be assigned the same Site of Origin attribute, even if + a site is multiply connected to a single PE, or is connected to + multiple PEs. Distinct Site of Origin attributes must be used + for distinct sites. This attribute could be encoded as an + extended BGP communities attribute (section 4.2.1). + + - VPN of Origin + + See section 4.2.1. + + + +Rosen & Rekhter Informational [Page 18] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + - Target VPN + + See section 4.2.1. + +7. How CEs learn Routes from PEs + + In this section, we assume that the CE device is a router. + + In general, a PE may distribute to a CE any route which the PE has + placed in the forwarding table which it uses to route packets from + that CE. There is one exception: if a route's Site of Origin + attribute identifies a particular site, that route must never be + redistributed to any CE at that site. + + In most cases, however, it will be sufficient for the PE to simply + distribute the default route to the CE. (In some cases, it may even + be sufficient for the CE to be configured with a default route + pointing to the PE.) This will generally work at any site which does + not itself need to distribute the default route to other sites. + (E.g., if one site in a corporate VPN has the corporation's access to + the Internet, that site might need to have default distributed to the + other site, but one could not distribute default to that site + itself.) + + Whatever procedure is used to distribute routes from CE to PE will + also be used to distribute routes from PE to CE. + +8. What if the CE Supports MPLS? + + In the case where the CE supports MPLS, AND is willing to import the + complete set of routes from its VPNs, the PE can distribute to it a + label for each such route. When the PE receives a packet from the CE + with such a label, it (a) replaces that label with the corresponding + label that it learned via BGP, and (b) pushes on a label + corresponding to the BGP next hop for the corresponding route. + +8.1. Virtual Sites + + If the CE/PE route distribution is done via BGP, the CE can use MPLS + to support multiple virtual sites. The CE may itself contain a + separate forwarding table for each virtual site, which it populates + as indicated by the VPN of Origin and Target VPN attributes of the + routes it receives from the PE. If the CE receives the full set of + routes from the PE, the PE will not need to do any address lookup at + all on packets received from the CE. Alternatively, the PE may in + some cases be able to distribute to the CE a single (labeled) default + route for each VPN. Then when the PE receives a labeled packet from + + + + +Rosen & Rekhter Informational [Page 19] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + the CE, it would know which forwarding table to look in; the label + placed on the packet by the CE would identify only the virtual site + from which the packet is coming. + +8.2. Representing an ISP VPN as a Stub VPN + + If a particular VPN is actually an ISP, but its CE routers support + MPLS, then the VPN can actually be treated as a stub VPN. The CE and + PE routers need only exchange routes which are internal to the VPN. + The PE router would distribute to the CE router a label for each of + these routes. Routers at different sites in the VPN can then become + BGP peers. When the CE router looks up a packet's destination + address, the routing lookup always resolves to an internal address, + usually the address of the packet's BGP next hop. The CE labels the + packet appropriately and sends the packet to the PE. + +9. Security + + Under the following conditions: + + a) labeled packets are not accepted by backbone routers from + untrusted or unreliable sources, unless it is known that such + packets will leave the backbone before the IP header or any + labels lower in the stack will be inspected, and + + b) labeled VPN-IPv4 routes are not accepted from untrusted or + unreliable sources, + + the security provided by this architecture is virtually identical to + that provided to VPNs by Frame Relay or ATM backbones. + + It is worth noting that the use of MPLS makes it much simpler to + provide this level of security than would be possible if one + attempted to use some form of IP-within-IP tunneling in place of + MPLS. It is a simple matter to refuse to accept a labeled packet + unless the first of the above conditions applies to it. It is rather + more difficult to configure the a router to refuse to accept an IP + packet if that packet is an IP-within-IP tunnelled packet which is + going to a "wrong" place. + + The use of MPLS also allows a VPN to span multiple SPs without + depending in any way on the inter-domain distribution of IPv4 routing + information. + + It is also possible for a VPN user to provide himself with enhanced + security by making use of Tunnel Mode IPSEC [5]. This is discussed + in the remainder of this section. + + + + +Rosen & Rekhter Informational [Page 20] + +RFC 2547 BGP/MPLS VPNs March 1999 + + +9.1. Point-to-Point Security Tunnels between CE Routers + + A security-conscious VPN user might want to ensure that some or all + of the packets which traverse the backbone are authenticated and/or + encrypted. The standard way to obtain this functionality today would + be to create a "security tunnel" between every pair of CE routers in + a VPN, using IPSEC Tunnel Mode. + + However, the procedures described so far do not enable the CE router + transmitting a packet to determine the identify of the next CE router + that the packet will traverse. Yet that information is required in + order to use Tunnel Mode IPSEC. So we must extend those procedures + to make this information available. + + A way to do this is suggested in [6]. Every VPN-IPv4 route can have + an attribute which identifies the next CE router that will be + traversed if that route is followed. If this information is provided + to all the CE routers in the VPN, standard IPSEC Tunnel Mode can be + used. + + If the CE and PE are BGP peers, it is natural to present this + information as a BGP attribute. + + Each CE that is to use IPSEC should also be configured with a set of + address prefixes, such that it is prohibited from sending insecure + traffic to any of those addresses. This prevents the CE from sending + insecure traffic if, for some reason, it fails to obtain the + necessary information. + + When MPLS is used to carry packets between the two endpoints of an + IPSEC tunnel, the IPSEC outer header does not really perform any + function. It might be beneficial to develop a form of IPSEC tunnel + mode which allows the outer header to be omitted when MPLS is used. + +9.2. Multi-Party Security Associations + + Instead of setting up a security tunnel between each pair of CE + routers, it may be advantageous to set up a single, multiparty + security association. In such a security association, all the CE + routers which are in a particular VPN would share the same security + parameters (.e.g., same secret, same algorithm, etc.). Then the + ingress CE wouldn't have to know which CE is the next one to receive + the data, it would only have to know which VPN the data is going to. + A CE which is in multiple VPNs could use different security + parameters for each one, thus protecting, e.g., intranet packets from + being exposed to the extranet. + + + + + +Rosen & Rekhter Informational [Page 21] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + With such a scheme, standard Tunnel Mode IPSEC could not be used, + because there is no way to fill in the IP destination address field + of the "outer header". However, when MPLS is used for forwarding, + there is no real need for this outer header anyway; the PE router can + use MPLS to get a packet to a tunnel endpoint without even knowing + the IP address of that endpoint; it only needs to see the IP + destination address of the "inner header". + + A significant advantage of a scheme like this is that it makes + routing changes (in particular, a change of egress CE for a + particular address prefix) transparent to the security mechanism. + This could be particularly important in the case of multi-provider + VPNs, where the need to distribute information about such routing + changes simply to support the security mechanisms could result in + scalability issues. + + Another advantage is that it eliminates the need for the outer IP + header, since the MPLS encapsulation performs its role. + +10. Quality of Service + + Although not the focus of this paper, Quality of Service is a key + component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS + capabilities can be applied to labeled packets through the use of the + "experimental" bits in the shim header [10], or, where ATM is used as + the backbone, through the use of ATM QoS capabilities. The traffic + engineering work discussed in [1] is also directly applicable to + MPLS/BGP VPNs. Traffic engineering could even be used to establish + LSPs with particular QoS characteristics between particular pairs of + sites, if that is desirable. Where an MPLS/BGP VPN spans multiple + SPs, the architecture described in [7] may be useful. An SP may + apply either intserv or diffserv capabilities to a particular VPN, as + appropriate. + +11. Scalability + + We have discussed scalability issues throughout this paper. In this + section, we briefly summarize the main characteristics of our model + with respect to scalability. + + The Service Provider backbone network consists of (a) PE routers, (b) + BGP Route Reflectors, (c) P routers (which are neither PE routers nor + Route Reflectors), and, in the case of multi-provider VPNs, (d) + ASBRs. + + + + + + + +Rosen & Rekhter Informational [Page 22] + +RFC 2547 BGP/MPLS VPNs March 1999 + + + P routers do not maintain any VPN routes. In order to properly + forward VPN traffic, the P routers need only maintain routes to the + PE routers and the ASBRs. The use of two levels of labeling is what + makes it possible to keep the VPN routes out of the P routers. + + A PE router to maintains VPN routes, but only for those VPNs to which + it is directly attached. + + Route reflectors and ASBRs can be partitioned among VPNs so that each + partition carries routes for only a subset of the VPNs provided by + the Service Provider. Thus no single Route Reflector or ASBR is + required to maintain routes for all the VPNs. + + As a result, no single component within the Service Provider network + has to maintain all the routes for all the VPNs. So the total + capacity of the network to support increasing numbers of VPNs is not + limited by the capacity of any individual component. + +12. Intellectual Property Considerations + + Cisco Systems may seek patent or other intellectual property + protection for some of all of the technologies disclosed in this + document. If any standards arising from this document are or become + protected by one or more patents assigned to Cisco Systems, Cisco + intends to disclose those patents and license them on reasonable and + non-discriminatory terms. + +13. Security Considerations + + Security issues are discussed throughout this memo. + +14. Acknowledgments + + Significant contributions to this work have been made by Ravi + Chandra, Dan Tappan and Bob Thomas. + + + + + + + + + + + + + + + + +Rosen & Rekhter Informational [Page 23] + +RFC 2547 BGP/MPLS VPNs March 1999 + + +15. Authors' Addresses + + Eric C. Rosen + Cisco Systems, Inc. + 250 Apollo Drive + Chelmsford, MA, 01824 + + EMail: erosen@cisco.com + + + Yakov Rekhter + Cisco Systems, Inc. + 170 Tasman Drive + San Jose, CA, 95134 + + EMail: yakov@cisco.com + +16. References + + [1] Awduche, Berger, Gan, Li, Swallow, and Srinavasan, "Extensions + to RSVP for LSP Tunnels", Work in Progress. + + [2] Bates, T. and R. Chandrasekaran, "BGP Route Reflection: An + alternative to full mesh IBGP", RFC 1966, June 1996. + + [3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol + Extensions for BGP4", RFC 2283, February 1998. + + [4] Gleeson, Heinanen, and Armitage, "A Framework for IP Based + Virtual Private Networks", Work in Progress. + + [5] Kent and Atkinson, "Security Architecture for the Internet + Protocol", RFC 2401, November 1998. + + [6] Li, "CPE based VPNs using MPLS", October 1998, Work in Progress. + + [7] Li, T. and Y. Rekhter, "A Provider Architecture for + Differentiated Services and Traffic Engineering (PASTE)", RFC + 2430, October 1998. + + [8] Rekhter and Rosen, "Carrying Label Information in BGP4", Work in + Progress. + + [9] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching + Architecture", Work in Progress. + + [10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS + Label Stack Encoding", Work in Progress. + + + +Rosen & Rekhter Informational [Page 24] + +RFC 2547 BGP/MPLS VPNs March 1999 + + +17. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + + + + + + + + + + + + + + + + + + + + + + + + +Rosen & Rekhter Informational [Page 25] + |