idnits 2.17.1 draft-rosen-vpn-mpls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2023-02-07) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 538 has weird spacing: '...es only a set...' == Line 663 has weird spacing: '...and one meani...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1998) is 8820 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 1966 (ref. '2') (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 2283 (ref. '3') (Obsoleted by RFC 2858) -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: draft-ietf-ipsec-arch-sec has been published as RFC 2401 -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 2430 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Yakov Rekhter 4 Expiration Date: June 1999 Cisco Systems, Inc. 6 December 1998 8 BGP/MPLS VPNs 10 draft-rosen-vpn-mpls-01.txt 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 This document describes a method by which a Service Provider with an 33 IP backbone may provide VPNs for its customers. MPLS is used for 34 forwarding packets over the backbone, and BGP is used for 35 distributing routes over the backbone. The primary goal of this 36 method is to support the outsourcing of IP backbone services for 37 enterprise networks. It does so in a manner which is simple for the 38 enterprise, while still scalable and flexible for the Service 39 Provider, and while allowing the Service Provider to add value. These 40 techniques can also be used to provide a VPN which itself provides IP 41 service to customers. 43 Table of Contents 45 1 Introduction ....................................... 3 46 1.1 Virtual Private Networks ........................... 3 47 1.2 Edge Devices ....................................... 4 48 1.3 VPNs with Overlapping Address Spaces ............... 5 49 1.4 VPNs with Different Routes to the Same System ...... 5 50 1.5 Multiple Forwarding Tables in PEs .................. 5 51 1.6 SP Backbone Routers ................................ 6 52 1.7 Security ........................................... 6 53 2 Sites and CEs ...................................... 7 54 3 Per-Site Forwarding Tables in the PEs .............. 7 55 3.1 Virtual Sites ...................................... 9 56 4 VPN Route Distribution via BGP ..................... 9 57 4.1 The VPN-IPv4 Address Family ........................ 10 58 4.2 Controlling Route Distribution ..................... 11 59 4.2.1 The Target VPN Attribute ........................... 11 60 4.2.2 Route Distribution Among PEs by BGP ................ 13 61 4.2.3 The VPN of Origin Attribute ........................ 15 62 4.2.4 Building VPNs using Target and Origin Attributes ... 15 63 5 Forwarding Across the Backbone ..................... 16 64 6 How PEs Learn Routes from CEs ...................... 17 65 7 How CEs learn Routes from PEs ...................... 20 66 8 What if the CE Supports MPLS? ...................... 20 67 8.1 Virtual Sites ...................................... 21 68 8.2 Representing an ISP VPN as a Stub VPN .............. 21 69 9 Security ........................................... 21 70 9.1 Point-to-Point Security Tunnels between CE Routers . 22 71 9.2 Multi-Party Security Associations .................. 23 72 10 Quality of Service ................................. 23 73 11 Scalability ........................................ 24 74 12 Intellectual Property Considerations ............... 24 75 13 Acknowledgments .................................... 25 76 14 Authors' Addresses ................................. 25 77 15 References ......................................... 25 79 1. Introduction 81 1.1. Virtual Private Networks 83 Consider a set of "sites" which are attached to a common network 84 which we may call the "backbone". Let's apply some policy to create a 85 number of subsets of that set, and let's impose the following rule: 86 two sites may have IP interconnectivity over that backbone only if at 87 least one of these subsets contains them both. 89 The subsets we have created are "Virtual Private Networks" (VPNs). 90 Two sites have IP connectivity over the common backbone only if there 91 is some VPN which contains them both. Two sites which have no VPN in 92 common have no connectivity over that backbone. 94 If all the sites in a VPN are owned by the same enterprise, the VPN 95 is a corporate "intranet". If the various sites in a VPN are owned 96 by different enterprises, the VPN is an "extranet". A site can be in 97 more than one VPN; e.g., in an intranet and several extranets. We 98 regard both intranets and extranets as VPNs. In general, when we use 99 the term VPN we will not be distinguishing between intranets and 100 extranets. 102 We wish to consider the case in which the backbone is owned and 103 operated by one or more Service Providers (SPs). The owners of the 104 sites are the "customers" of the SPs. The policies that determine 105 whether a particular collection of sites is a VPN are the policies of 106 the customers. Some customers will want the implementation of these 107 policies to be entirely the responsibility of the SP. Other 108 customers may want to implement these policies themselves, or to 109 share with the SP the responsibility for implementing these policies. 110 In this document, we are primarily discussing mechanisms that may be 111 used to implement these policies. The mechanisms we describe are 112 general enough to allow these policies to be implemented either by 113 the SP alone, or by a VPN customer together with the SP. Most of the 114 discussion is focused on the former case, however. 116 The mechanisms discussed in this document allow the implementation of 117 a wide range of policies. For example, within a given VPN, we can 118 allow every site to have a direct route to every other site ("full 119 mesh"), or we can restrict certain pairs of sites from having direct 120 routes to each other ("partial mesh"). 122 In this document, we are particularly interested in the case where 123 the common backbone offers an IP service. We are primarily concerned 124 with the case in which an enterprise is outsourcing its backbone to a 125 service provider, or perhaps to a set of service providers, with 126 which it maintains contractual relationships. We are not focused on 127 providing VPNs over the public Internet. 129 In the rest of this introduction, we specify some properties which 130 VPNs should have. The remainder of this document outlines a VPN 131 model which has all these properties. The VPN Model of this document 132 appears to be an instance of the framework described in [4]. 134 1.2. Edge Devices 136 We suppose that at each site, there are one or more Customer Edge 137 (CE) devices, each of which is attached via some sort of data link 138 (e.g., PPP, ATM, ethernet, Frame Relay, GRE tunnel, etc.) to one or 139 more Provider Edge (PE) routers. 141 If a particular site has a single host, that host may be the CE 142 device. If a particular site has a single subnet, that the CE device 143 may be a switch. In general, the CE device can be expected to be a 144 router, which we call the CE router. 146 We will say that a PE router is attached to a particular VPN if it is 147 attached to a CE device which is in that VPN. Similarly, we will say 148 that a PE router is attached to a particular site if it is attached 149 to a CE device which is in that site. 151 When the CE device is a router, it is a routing peer of the PE(s) to 152 which it is attached, but is not a routing peer of CE routers at 153 other sites. Routers at different sites do not directly exchange 154 routing information with each other; in fact, they do not even need 155 to know of each other at all (except in the case where this is 156 necessary for security purposes, see section 9). As a consequence, 157 very large VPNs (i.e., VPNs with a very large number of sites) are 158 easily supported, while the routing strategy for each individual site 159 is greatly simplified. 161 It is important to maintain clear administrative boundaries between 162 the SP and its customers (cf. [4]). The PE and P routers should be 163 administered solely by the SP, and the SP's customers should not have 164 any management access to it. The CE devices should be administered 165 solely by the customer (unless the customer has contracted the 166 management services out to the SP). 168 1.3. VPNs with Overlapping Address Spaces 170 We assume that any two non-intersecting VPNs (i.e., VPNs with no 171 sites in common) may have overlapping address spaces; the same 172 address may be reused, for different systems, in different VPNs. As 173 long as a given endsystem has an address which is unique within the 174 scope of the VPNs that it belongs to, the endsystem itself does not 175 need to know anything about VPNs. 177 In this model, the VPN owners do not have a backbone to administer, 178 not even a "virtual backbone." Nor do the SPs have to administer a 179 separate backbone or "virtual backbone" for each VPN. Site-to-site 180 routing in the backbone is optimal (within the constraints of the 181 policies used to form the VPNs), and is not constrained in any way by 182 an artificial "virtual topology" of tunnels. 184 1.4. VPNs with Different Routes to the Same System 186 Although a site may be in multiple VPNs, it is not necessarily the 187 case that the route to a given system at that site should be the same 188 in all the VPNs. Suppose, for example, we have an intranet 189 consisting of sites A, B, and C, and an extranet consisting of A, B, 190 C, and the "foreign" site D. Suppose that at site A there is a 191 server, and we want clients from B, C, or D to be able to use that 192 server. Suppose also that at site B there is a firewall. We want 193 all the traffic from site D to the server to pass through the 194 firewall, so that traffic from the extranet can be access controlled. 195 However, we don't want traffic from C to pass through the firewall on 196 the way to the server, since this is intranet traffic. 198 This means that it needs to be possible to set up two routes to the 199 server. One route, used by sites B and C, takes the traffic directly 200 to site A. The second route, used by site D, takes the traffic 201 instead to the firewall at site B. If the firewall allows the 202 traffic to pass, it then appears to be traffic coming from site B, 203 and follows the route to site A. 205 1.5. Multiple Forwarding Tables in PEs 207 Each PE router needs to maintain a number of separate forwarding 208 tables. Every site to which the PE is attached must be mapped to one 209 of those forwarding tables. When a packet is received from a 210 particular site, the forwarding table associated with that site is 211 consulted in order to determine how to route the packet. The 212 forwarding table associated with a particular site S is populated 213 only with routes that lead to other sites which have at least one VPN 214 in common with S. This prevents communication between sites which 215 have no VPN in common, and it allows two VPNs with no site in common 216 to use address spaces that overlap with each other. 218 1.6. SP Backbone Routers 220 The SP's backbone consists of the PE routers, as well as other 221 routers (P routers) which do not attach to CE devices. 223 If every router in an SP's backbone had to maintain routing 224 information for all the VPNs supported by the SP, this model would 225 have severe scalability problems; the number of sites that could be 226 supported would be limited by the amount of routing information that 227 could be held in a single router. It is important to require 228 therefore that the routing information about a particular VPN be 229 present ONLY in those PE routers which attach to that VPN. In 230 particular, the P routers should not need to have ANY per-VPN routing 231 information whatsoever. 233 VPNs may span multiple service providers. We assume though that when 234 the path between PE routers crosses a boundary between SP networks, 235 it does so via a private peering arrangement, at which there exists 236 mutual trust between the two providers. In particular, each provider 237 must trust the other to pass it only correct routing information, and 238 to pass it labeled (in the sense of MPLS [9]) packets only if those 239 packets have been labeled by trusted sources. We also assume that it 240 is possible for label switched paths to cross the boundary between 241 service providers. 243 1.7. Security 245 A VPN model should, even without the use of cryptographic security 246 measures, provide a level of security equivalent to that obtainable 247 when a level 2 backbone (e.g., Frame Relay) is used. That is, in the 248 absence of misconfiguration or deliberate interconnection of 249 different VPNs, it should not be possible for systems in one VPN to 250 gain access to systems in another VPN. 252 It should also be possible to deploy standard security procedures. 254 2. Sites and CEs 256 From the perspective of a particular backbone network, a set of IP 257 systems constitutes a site if those systems have mutual IP 258 interconnectivity, and communication between them occurs without use 259 of the backbone. In general, a site will consist of a set of systems 260 which are in geographic proximity. However, this is not universally 261 true; two geographic locations connected via a leased line, over 262 which OSPF is running, will constitute a single site, because 263 communication between the two locations does not involve the use of 264 the backbone. 266 A CE device is always regarded as being in a single site (though as 267 we shall see, a site may consist of multiple "virtual sites"). A 268 site, however, may belong to multiple VPNs. 270 A PE router may attach to CE devices in any number of different 271 sites, whether those CE devices are in the same or in different VPNs. 272 A CE device may, for robustness, attach to multiple PE routers, of 273 the same or of different service providers. If the CE device is a 274 router, the PE router and the CE router will appear as router 275 adjacencies to each other. 277 While the basic unit of interconnection is the site, the architecture 278 described herein allows a finer degree of granularity in the control 279 of interconnectivity. For example, certain systems at a site may be 280 members of an intranet as well as members of one or more extranets, 281 while other systems at the same site may be restricted to being 282 members of the intranet only. 284 3. Per-Site Forwarding Tables in the PEs 286 Each PE router maintains one or more "per-site forwarding tables." 287 Every site to which the PE router is attached is associated with one 288 of these tables. A particular packet's IP destination address is 289 looked up in a particular per-site forwarding table only if that 290 packet has arrived directly from a site which is associated with that 291 table. 293 How are the per-site forwarding tables populated? 295 As an example, let PE1, PE2, and PE3 be three PE routers, and let 296 CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from 297 CE1, the routes which are reachable at CE1's site. If PE2 and PE3 298 are attached respectively to CE2 and CE3, and there is some VPN V 299 containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2 300 and PE3 the routes which it has learned from CE1. PE2 and PE3 use 301 these routes to populate the forwarding tables which they associate 302 respectively with the sites of CE2 and CE3. Routes from sites which 303 are not in VPN V do not appear in these forwarding tables, which 304 means that packets from CE2 or CE3 cannot be sent to sites which are 305 not in VPN V. 307 If a site is in multiple VPNs, the forwarding table associated with 308 that site can contain routes from the full set of VPNs of which the 309 site is a member. 311 A PE generally maintains only one forwarding table per site, even if 312 it is multiply connected to that site. Also, different sites can 313 share the same forwarding table if they are meant to use exactly the 314 same set of routes. 316 Suppose a packet is received by a PE router from a particular 317 directly attached site, but the packet's destination address does not 318 match any entry in the forwarding table associated with that site. 319 If the SP is not providing Internet access for that site, then the 320 packet is discarded as undeliverable. If the SP is providing 321 Internet access for that site, then the PE's Internet forwarding 322 table will be consulted. This means that in general, only one 323 forwarding table per PE need ever contain routes from the Internet, 324 even if Internet access is provided. 326 To maintain proper isolation of one VPN from another, it is important 327 that no router in the backbone accept a labeled packet from any 328 adjacent non-backbone device unless (a) the label at the top of the 329 label stack was actually distributed by the backbone router to the 330 non-backbone device, and (b) the backbone router can determine that 331 use of that label will cause the packet to leave the backbone before 332 any labels lower in the stack will be inspected, and before the IP 333 header will be inspected. These restrictions are necessary in order 334 to prevent packets from entering a VPN where they do not belong. 336 The per-site forwarding tables in a PE are ONLY used for packets 337 which arrive from a site which is directly attached to the PE. They 338 are not used for routing packets which arrive from other routers that 339 belong to the SP backbone. As a result, there may be multiple 340 different routes to the same system, where the route followed by a 341 given packet is determined by the site from which the packet enters 342 the backbone. E.g., one may have one route to a given system for 343 packets from the extranet (where the route leads to a firewall), and 344 a different route to the same system for packets from the intranet 345 (including packets that have already passed through the firewall). 347 3.1. Virtual Sites 349 In some cases, a particular site may be divided by the customer into 350 several virtual sites, perhaps by the use of VLANs. Each virtual 351 site may be a member of a different set of VPNs. The PE then needs to 352 contain a separate forwarding table for each virtual site. For 353 example, if a CE supports VLANs, and wants each VLAN mapped to a 354 separate VPN, the packets sent between CE and PE could be contained 355 in the site's VLAN encapsulation, and this could be used by the PE, 356 along with the interface over which the packet is received, to assign 357 the packet to a particular virtual site. 359 Alternatively, one could divide the interface into multiple "sub- 360 interfaces" (particularly if the interface is Frame Relay or ATM), 361 and assign the packet to a VPN based on the sub-interface over which 362 it arrives. Or one could simply use a different interface for each 363 virtual site. In any case, only one CE router is ever needed per 364 site, even if there are multiple virtual sites. Of course, a 365 different CE router could be used for each virtual site, if that is 366 desired. 368 Note that in all these cases, the mechanisms, as well as the policy, 369 for controlling which traffic is in which VPN are in the hand of the 370 customer. 372 If it is desired to have a particular host be in multiple virtual 373 sites, then that host must determine, for each packet, which virtual 374 site the packet is associated with. It can do this, e.g., by sending 375 packets from different virtual sites on different VLANs, our out 376 different network interfaces. 378 These schemes do NOT require the CE to support MPLS. Section 8 379 contains a brief discussion of how the CE might support multiple 380 virtual sites if it does support MPLS. 382 4. VPN Route Distribution via BGP 384 PE routers use BGP to distribute VPN routes to each other (more 385 accurately, to cause VPN routes to be distributed to each other). 387 A BGP speaker can only install and distribute one route to a given 388 address prefix. Yet we allow each VPN to have its own address space, 389 which means that the same address can be used in any number of VPNs, 390 where in each VPN the address denotes a different system. It follows 391 that we need to allow BGP to install and distribute multiple routes 392 to a single IP address prefix. Further, we must ensure that POLICY 393 is used to determine which sites can be use which routes; given that 394 several such routes are installed by BGP, only one such must appear 395 in any particular per-site forwarding table. 397 We meet these goals by the use of a new address family, as specified 398 below. 400 4.1. The VPN-IPv4 Address Family 402 The BGP Multiprotocol Extensions [3] allow BGP to carry routes from 403 multiple "address families". We introduce the notion of the "VPN- 404 IPv4 address family". A VPN-IPv4 address is a 12-byte quantity, 405 beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 406 4-byte IPv4 address. If two VPNs use the same IPv4 address prefix, 407 the PEs translate these into unique VPN-IPv4 address prefixes. This 408 ensures that if the same address is used in two different VPNs, it is 409 possible to install two completely different routes to that address, 410 one for each VPN. 412 The RD does not by itself impose any semantics; it contains no 413 information about the origin of the route or about the set of VPNs to 414 which the route is to be distributed. The purpose of the RD is 415 solely to allow one to create distinct routes to a common IPv4 416 address prefix. Other means are used to determine where to 417 redistribute the route (see section 4.2). 419 The RD can also be used to create multiple different routes to the 420 very same system. In section 3, we gave an example where the route 421 to a particular server had to be different for intranet traffic than 422 for extranet traffic. This can be achieved by creating two different 423 VPN-IPv4 routes that have the same IPv4 part, but different RDs. 424 This allows BGP to install multiple different routes to the same 425 system, and allows policy to be used (see section 4.2.3) to decide 426 which packets use which route. 428 The RDs are structured so that every service provider can administer 429 its own "numbering space" (i.e., can make its own assignments of 430 RDs), without conflicting with the RD assignments made by any other 431 service provider. An RD consists of a two-byte type field, an 432 administrator field, and an assigned number field. The value of the 433 type field determines the lengths of the other two fields, as well as 434 the semantics of the administrator field. The administrator field 435 identifies an assigned number authority, and the assigned number 436 field contains a number which has been assigned, by the identified 437 authority, for a particular purpose. For example, one could have an 438 RD whose administrator field contains an Autonomous System number 439 (ASN), and whose (4-byte) number field contains a number assigned by 440 the SP to whom IANA has assigned that ASN. 442 RDs are given this structure in order to ensure that an SP which 443 provides VPN backbone service can always create a unique RD when it 444 needs to do so. However, the structuring provides no semantics. When 445 BGP compares two such address prefixes, it ignores the structure 446 entirely. 448 If the Administrator subfield and the Assigned Number subfield of a 449 VPN-IPv4 address are both set to all zeroes, the VPN-IPv4 address is 450 considered to have exactly the same meaning as the corresponding 451 globally unique IPv4 address. In particular, this VPN-IPv4 address 452 and the corresponding globally unique IPv4 address will be considered 453 comparable by BGP. In all other cases, a VPN-IPv4 address and its 454 corresponding globally unique IPv4 address will be considered 455 noncomparable by BGP. 457 A given per-site forwarding table will only have one VPN-IPv4 route 458 for any given IPv4 address prefix. When a packet's destination 459 address is matched against a VPN-IPv4 route, only the IPv4 part is 460 actually matched. 462 A PE needs to be configured to associate routes which lead to 463 particular CE with a particular RD. The PE may be configured to 464 associate all routes leading to the same CE with the same RD, or it 465 may be configured to associate different routes with different RDs, 466 even if they lead to the same CE. 468 4.2. Controlling Route Distribution 470 In this section, we discuss the way in which the distribution of the 471 VPN-IPv4 routes is controlled. 473 4.2.1. The Target VPN Attribute 475 Every per-site forwarding table is associated with one or more 476 "Target VPN" attributes. 478 When a VPN-IPv4 route is created by a PE router, it is associated 479 with one or more "Target VPN" attributes. These are carried in BGP 480 as attributes of the route. 482 Any route associated with Target VPN T must be distributed to every 483 PE router that has a forwarding table associated with Target VPN T. 484 When such a route is received by a PE router, it is eligible to be 485 installed in each of the PE's per-site forwarding tables that is 486 associated with Target VPN T. (Whether it actually gets installed 487 depends on the outcome of the BGP decision process.) 488 In essence, a Target VPN attribute identifies a set of sites. 489 Associating a particular Target VPN attribute with a route allows 490 that route to be placed in the per-site forwarding tables that are 491 used for routing traffic which is received from the corresponding 492 sites. 494 There is a set of Target VPNs that a PE router attaches to a route 495 received from site S. And there is a set of Target VPNs that a PE 496 router uses to determine whether a route received from another PE 497 router could be placed in the forwarding table associated with site 498 S. The two sets are distinct, and need not be the same. 500 The function performed by the Target VPN attribute is similar to that 501 performed by the BGP Communities Attribute. However, the format of 502 the latter is inadequate, since it allows only a two-byte numbering 503 space. It would be fairly straightforward to extend the BGP 504 Communities Attribute to provide a larger numbering space. It should 505 also be possible to structure the format, similar to what we have 506 described for RDs (see section 4.1), so that a type field defines the 507 length of an administrator field, and the remainder of the attribute 508 is a number from the specified administrator's numbering space. 510 When a BGP speaker has received two routes to the same VPN-IPv4 511 prefix, it chooses one, according to the BGP rules for route 512 preference. 514 Note that a route can only have one RD, but it can have multiple 515 Target VPNs. In BGP, scalability is improved if one has a single 516 route with multiple attributes, as opposed to multiple routes. One 517 could eliminate the Target VPN attribute by creating more routes 518 (i.e., using more RDs), but the scaling properties would be less 519 favorable. 521 How does a PE determine which Target VPN attributes to associate with 522 a given route? There are a number of different possible ways. The 523 PE might be configured to associate all routes that lead to a 524 particular site with a particular Target VPN. Or the PE might be 525 configured to associate certain routes leading to a particular site 526 with one Target VPN, and certain with another. Or the CE router, 527 when it distributes these routes to the PE (see section 6), might 528 specify one or more Target VPNs for each route. The latter method 529 shifts the control of the mechanisms used to implement the VPN 530 policies from the SP to the customer. If this method is used, it may 531 still be desirable to have the PE eliminate any Target VPNs that, 532 according to its own configuration, are not allowed, and/or to add in 533 some Target VPNs that according to its own configuration are 534 mandatory. 536 It might be more accurate, if less suggestive, to call this attribute 537 the "Route Target" attribute instead of the "VPN Target" attribute. 538 It really identifies only a set of sites which will be able to use 539 the route, without prejudice to whether those sites constitute what 540 might intuitively be called a VPN. 542 4.2.2. Route Distribution Among PEs by BGP 544 If two sites of a VPN attach to PEs which are in the same Autonomous 545 System, the PEs can distribute VPN-IPv4 routes to each other by means 546 of an IBGP connection between them. Alternatively, each can have an 547 IBGP connection to a route reflector. 549 If two sites of VPN are in different Autonomous Systems (e.g., 550 because they are connected to different SPs), then a PE router will 551 need to use IBGP to redistribute VPN-IPv4 routes either to an 552 Autonomous System Border Router (ASBR), or to a route reflector of 553 which an ASBR is a client. The ASBR will then need to use EBGP to 554 redistribute those routes to an ASBR in another AS. This allows one 555 to connect different VPN sites to different Service Providers. 556 However, VPN-IPv4 routes should only be accepted on EBGP connections 557 at private peering points, as part of a trusted arrangement between 558 SPs. VPN-IPv4 routes should neither be distributed to nor accepted 559 from the public Internet. 561 If there are many VPNs having sites attached to different Autonomous 562 Systems, there does not need to be a single ASBR between those two 563 ASes which holds all the routes for all the VPNs; there can be 564 multiple ASBRs, each of which holds only the routes for a particular 565 subset of the VPNs. 567 When a PE router distributes a VPN-IPv4 route via BGP, it uses its 568 own address as the "BGP next hop". It also assigns and distributes 569 an MPLS label. (Essentially, PE routers distribute not VPN-IPv4 570 routes, but Labeled VPN-IPv4 routes. Cf. [8]) When the PE processes a 571 received packet that has this label at the top of the stack, the PE 572 will pop the stack, and send the packet directly to the site from to 573 which the route leads. This will usually mean that it just sends the 574 packet to the CE router from which it learned the route. The label 575 may also determine the data link encapsulation. 577 In most cases, the label assigned by a PE will cause the packet to be 578 sent directly to a CE, and the PE which receives the labeled packet 579 will not look up the packet's destination address in any forwarding 580 table. However, it is also possible for the PE to assign a label 581 which implicitly identifies a particular forwarding table. In this 582 case, the PE receiving a packet that label would look up the packet's 583 destination address in one of its forwarding tables. While this can 584 be very useful in certain circumstances, we do not consider it 585 further in this paper. 587 Note that the MPLS label that is distributed in this way is only 588 usable if there is a label switched path between the router that 589 installs a route and the BGP next hop of that route. We do not make 590 any assumption about the procedure used to set up that label switched 591 path. It may be set up on a pre-established basis, or it may be set 592 up when a route which would need it is installed. It may be a "best 593 effort" route, or it may be a traffic engineered route. Between a 594 particular PE router and its BGP next hop for a particular route 595 there may be one LSP, or there may be several, perhaps with different 596 QoS characteristics. All that matters for the VPN architecture is 597 that some label switched path between the router and its BGP next hop 598 exists. 600 All the usual techniques for using route reflectors [2] to improve 601 scalability, e.g., route reflector hierarchies, are available. If 602 route reflectors are used, there is no need to have any one route 603 reflector know all the VPN-IPv4 routes for all the VPNs supported by 604 the backbone. One can have separate route reflectors, which do not 605 communicate with each other, each of which supports a subset of the 606 total set of VPNs. 608 If a given PE router is not attached to any of the Target VPNs of a 609 particular route, it should not receive that route; the other PE or 610 route reflector which is distributing routes to it should apply 611 outbound filtering to avoid sending it unnecessary routes. Of 612 course, if a PE router receives a route via BGP, and that PE is not 613 attached to any of the route's target VPNs, the PE should apply 614 inbound filtering to the route, neither installing nor redistributing 615 it. 617 A router which is not attached to any VPN, i.e., a P router, never 618 installs any VPN-IPv4 routes at all. 620 These distribution rules ensure that there is no one box which needs 621 to know all the VPN-IPv4 routes that are supported over the backbone. 622 As a result, the total number of such routes that can be supported 623 over the backbone is not bound by the capacity of any single device, 624 and therefore can increase virtually without bound. 626 4.2.3. The VPN of Origin Attribute 628 A VPN-IPv4 route may be optionally associated with a VPN of Origin 629 attribute. This attribute uniquely identifies a set of sites, and 630 identifies the corresponding route as having come from one of the 631 sites in that set. Typical uses of this attribute might be to 632 identify the enterprise which owns the site where the route leads, or 633 to identify the site's intranet. However, other uses are also 634 possible. This attribute could be encoded as an extended BGP 635 communities attribute. 637 In situations in which it is necessary to identify the source of a 638 route, it is this attribute, not the RD, which must be used. This 639 attribute may be used when "constructing" VPNs, as described below. 641 It might be more accurate, if less suggestive, to call this attribute 642 the "Route Origin" attribute instead of the "VPN of Origin" 643 attribute. It really identifies the route only has having come from 644 one of a particular set of sites, without prejudice as to whether 645 that particular set of sites really constitutes a VPN. 647 4.2.4. Building VPNs using Target and Origin Attributes 649 By setting up the Target VPN and VPN of Origin attributes properly, 650 one can construct different kinds of VPNs. 652 Suppose it is desired to create a Closed User Group (CUG) which 653 contains a particular set of sites. This can be done by creating a 654 particular Target VPN attribute value to represent the CUG. This 655 value then needs to be associated with the per-site forwarding tables 656 for each site in the CUG, and it needs to be associated with every 657 route learned from a site in the CUG. Any route which has this 658 Target VPN attribute will need to be redistributed so that it reaches 659 every PE router attached to one of the sites in the CUG. 661 Alternatively, suppose one desired, for whatever reason, to create a 662 "hub and spoke" kind of VPN. This could be done by the use of two 663 Target Attribute values, one meaning "Hub" and one meaning "Spoke". 664 Then routes from the spokes could be distributed to the hub, without 665 causing routes from the hub to be distributed to the spokes. 667 Suppose one has a number of sites which are in an intranet and an 668 extranet, as well as a number of sites which are in the intranet 669 only. Then there may be both intranet and extranet routes which have 670 a Target VPN identifying the entire set of sites. The sites which 671 are to have intranet routes only can filter out all routes with the 672 "wrong" VPN of Origin. 674 These two attributes allow great flexibility in allowing one to 675 control the distribution of routing information among various sets of 676 sites, which in turn provides great flexibility in constructing VPNs. 678 5. Forwarding Across the Backbone 680 If the intermediate routes in the backbone do not have any 681 information about the routes to the VPNs, how are packets forwarded 682 from one VPN site to another? 684 This is done by means of MPLS with a two-level label stack. 686 PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to 687 insert /32 address prefixes for themselves into the IGP routing 688 tables of the backbone. This enables MPLS, at each node in the 689 backbone network, to assign a label corresponding to the route to 690 each PE router. (Certain procedures for setting up label switched 691 paths in the backbone may not require the presence of the /32 address 692 prefixes.) 694 When a PE receives a packet from a CE device, it chooses a particular 695 per-site forwarding table in which to look up the packet's 696 destination address. Assume that a match is found. 698 If the packet is destined for a CE device attached to this same PE, 699 the packet is sent directly to that CE device. 701 If the packet is not destined for a CE device attached to this same 702 PE, the packet's "BGP Next Hop" is found, as well as the label which 703 that BGP next hop assigned for the packet's destination address. This 704 label is pushed onto the packet's label stack, and becomes the bottom 705 label. Then the PE looks up the IGP route to the BGP Next Hop, and 706 thus determines the IGP next hop, as well as the label assigned to 707 the address of the BGP next hop by the IGP next hop. This label gets 708 pushed on as the packet's top label, and the packet is then forwarded 709 to the IGP next hop. (If the BGP next hop is the same as the IGP 710 next hop, the second label may not need to be pushed on, however.) 712 At this point, MPLS will carry the packet across the backbone and 713 into the appropriate CE device. That is, all forwarding decisions by 714 P routers and PE routers are now made by means of MPLS, and the 715 packet's IP header is not looked at again until the packet reaches 716 the CE device. The final PE router will pop the last label from the 717 MPLS label stack before sending the packet to the CE device, thus the 718 CE device will just see an ordinary IP packet. (Though see section 8 719 for some discussion of the case where the CE desires to received 720 labeled packets.) 721 When a packet enters the backbone from a particular site via a 722 particular PE router, the packet's route is determined by the 723 contents of the forwarding table which that PE router associated with 724 that site. The forwarding tables of the PE router where the packet 725 leaves the backbone are not relevant. As a result, one may have 726 multiple routes to the same system, where the particular route chosen 727 for a particular packet is based on the site from which the packet 728 enters the backbone. 730 Note that it is the two-level labeling that makes it possible to keep 731 all the VPN routes out of the P routers, and this in turn is crucial 732 to ensuring the scalability of the model. The backbone does not even 733 need to have routes to the CEs, only to the PEs. 735 6. How PEs Learn Routes from CEs 737 The PE routers which attach to a particular VPN need to know, for 738 each of that VPN's sites, which addresses in that VPN are at each 739 site. 741 In the case where the CE device is a host or a switch, this set of 742 addresses will generally be configured into the PE router attaching 743 to that device. In the case where the CE device is a router, there 744 are a number of possible ways that a PE router can obtain this set of 745 addresses. 747 The PE translates these addresses into VPN-IPv4 addresses, using a 748 configured RD. The PE then treats these VPN-IPv4 routes as input to 749 BGP. In no case will routes from a site ever be leaked into the 750 backbone's IGP. 752 Exactly which PE/CE route distribution techniques are possible 753 depends on whether a particular CE is in a "transit VPN" or not. A 754 "transit VPN" is one which contains a router that receives routes 755 from a "third party" (i.e., from a router which is not in the VPN, 756 but is not a PE router), and that redistributes those routes to a PE 757 router. A VPN which is not a transit VPN is a "stub VPN". The vast 758 majority of VPNs, including just about all corporate enterprise 759 networks, would be expected to be "stubs" in this sense. 761 The possible PE/CE distribution techniques are: 763 1. Static routing (i.e., configuration) may be used. (This is 764 likely to be useful only in stub VPNs.) 766 2. PE and CE routers may be RIP peers, and the CE may use RIP to 767 tell the PE router the set of address prefixes which are 768 reachable at the CE router's site. When RIP is configured in 769 the CE, care must be taken to ensure that address prefixes from 770 other sites (i.e., address prefixes learned by the CE router 771 from the PE router) are never advertised to the PE. More 772 precisely: if a PE router, say PE1, receives a VPN-IPv4 route 773 R1, and as a result distributes an IPv4 route R2 to a CE, then 774 R2 must not be distributed back from that CE's site to a PE 775 router, say PE2, (where PE1 and PE2 may be the same router or 776 different routers), unless PE2 maps R2 to a VPN-IPv4 route 777 which is different than (i.e., contains a different RD than) 778 R1. 780 3. The PE and CE routers may be OSPF peers. In this case, the 781 site should be a single OSPF area, the CE should be an ABR in 782 that area, and the PE should be an ABR which is not in that 783 area. Also, the PE should report no router links other than 784 those to the CEs which are at the same site. (This technique 785 should be used only in stub VPNs.) 787 4. The PE and CE routers may be BGP peers, and the CE router may 788 use BGP (in particular, EBGP to tell the PE router the set of 789 address prefixes which are at the CE router's site. (This 790 technique can be used in stub VPNs or transit VPNs.) 792 From a purely technical perspective, this is by far the best 793 technique: 795 a) Unlike the IGP alternatives, this does not require the PE 796 to run multiple routing algorithm instances in order to 797 talk to multiple CEs 799 b) BGP is explicitly designed for just this function: 800 passing routing information between systems run by 801 different administrations 803 c) If the site contains "BGP backdoors", i.e., routers with 804 BGP connections to routers other than PE routers, this 805 procedure will work correctly in all circumstances. The 806 other procedures may or may not work, depending on the 807 precise circumstances. 809 d) Use of BGP makes it easy for the CE to pass attributes of 810 the routes to the PE. For example, the CE may suggest a 811 particular Target for each route, from among the Target 812 attributes that the PE is authorized to attach to the 813 route. 815 On the other hand, using BGP is likely to be something new for 816 the CE administrators, except in the case where the customer 817 itself is already an Internet Service Provider (ISP). 819 If a site is not in a transit VPN, note that it need not have a 820 unique Autonomous System Number (ASN). Every CE whose site 821 which is not in a transit VPN can use the same ASN. This can 822 be chosen from the private ASN space, and it will be stripped 823 out by the PE. Routing loops are prevented by use of the Site 824 of Origin Attribute (see below). 826 If a set of sites constitute a transit VPN, it is convenient to 827 represent them as a BGP Confederation, so that the internal 828 structure of the VPN is hidden from any router which is not 829 within the VPN. In this case, each site in the VPN would need 830 two BGP connections to the backbone, one which is internal to 831 the confederation and one which is external to it. The usual 832 intra-confederation procedures would have to be slightly 833 modified in order to take account for the fact that the 834 backbone and the sites may have different policies. The 835 backbone is a member of the confederation on one of the 836 connections, but is not a member on the other. These 837 techniques may be useful if the customer for the VPN service is 838 an ISP. This technique allows a customer that is an ISP to 839 obtain VPN backbone service from one of its ISP peers. 841 (However, if a VPN customer is itself an ISP, and its CE 842 routers support MPLS, a much simpler technique can be used, 843 wherein the ISP is regarded as a stub VPN. See section 8.) 845 When we do not need to distinguish among the different ways in which 846 a PE can be informed of the address prefixes which exist at a given 847 site, we will simply say that the PE has "learned" the routes from 848 that site. 850 Before a PE can redistribute a VPN-IPv4 route learned from a site, it 851 must assign certain attributes to the route. There are three such 852 attributes: 854 - Site of Origin 856 This attribute uniquely identifies the site from which the PE 857 router learned the route. All routes learned from a particular 858 site must be assigned the same Site of Origin attribute, even if 859 a site is multiply connected to a single PE, or is connected to 860 multiple PEs. Distinct Site of Origin attributes must be used 861 for distinct sites. This attribute could be encoded as an 862 extended BGP communities attribute (section 4.2.1). 864 - VPN of Origin 866 See section 4.2.1. 868 - Target VPN 870 See section 4.2.1. 872 7. How CEs learn Routes from PEs 874 In this section, we assume that the CE device is a router. 876 In general, a PE may distribute to a CE any route which the PE has 877 placed in the forwarding table which it uses to route packets from 878 that CE. There is one exception: if a route's Site of Origin 879 attribute identifies a particular site, that route must never be 880 redistributed to any CE at that site. 882 In most cases, however, it will be sufficient for the PE to simply 883 distribute the default route to the CE. (In some cases, it may even 884 be sufficient for the CE to be configured with a default route 885 pointing to the PE.) This will generally work at any site which does 886 not itself need to distribute the default route to other sites. 887 (E.g., if one site in a corporate VPN has the corporation's access to 888 the Internet, that site might need to have default distributed to the 889 other site, but one could not distribute default to that site 890 itself.) 892 Whatever procedure is used to distribute routes from CE to PE will 893 also be used to distribute routes from PE to CE. 895 8. What if the CE Supports MPLS? 897 In the case where the CE supports MPLS, AND is willing to import the 898 complete set of routes from its VPNs, the PE can distribute to it a 899 label for each such route. When the PE receives a packet from the CE 900 with such a label, it (a) replaces that label with the corresponding 901 label that it learned via BGP, and (b) pushes on a label 902 corresponding to the BGP next hop for the corresponding route. 904 8.1. Virtual Sites 906 If the CE/PE route distribution is done via BGP, the CE can use MPLS 907 to support multiple virtual sites. The CE may itself contain a 908 separate forwarding table for each virtual site, which it populates 909 as indicated by the VPN of Origin and Target VPN attributes of the 910 routes it receives from the PE. If the CE receives the full set of 911 routes from the PE, the PE will not need to do any address lookup at 912 all on packets received from the CE. Alternatively, the PE may in 913 some cases be able to distribute to the CE a single (labeled) default 914 route for each VPN. Then when the PE receives a labeled packet from 915 the CE, it would know which forwarding table to look in; the label 916 placed on the packet by the CE would identify only the virtual site 917 from which the packet is coming. 919 8.2. Representing an ISP VPN as a Stub VPN 921 If a particular VPN is actually an ISP, but its CE routers support 922 MPLS, then the VPN can actually be treated as a stub VPN. The CE and 923 PE routers need only exchange routes which are internal to the VPN. 924 The PE router would distribute to the CE router a label for each of 925 these routes. Routers at different sites in the VPN can then become 926 BGP peers. When the CE router looks up a packet's destination 927 address, the routing lookup always resolves to an internal address, 928 usually the address of the packet's BGP next hop. The CE labels the 929 packet appropriately and sends the packet to the PE. 931 9. Security 933 Under the following conditions: 935 a) labeled packets are not accepted by backbone routers from 936 untrusted or unreliable sources, unless it is known that such 937 packets will leave the backbone before the IP header or any 938 labels lower in the stack will be inspected, and 940 b) labeled VPN-IPv4 routes are not accepted from untrusted or 941 unreliable sources, 943 the security provided by this architecture is virtually identical to 944 that provided to VPNs by Frame Relay or ATM backbones. 946 It is worth noting that the use of MPLS makes it much simpler to 947 provide this level of security than would be possible if one 948 attempted to use some form of IP-within-IP tunneling in place of 949 MPLS. It is a simple matter to refuse to accept a labeled packet 950 unless the first of the above conditions applies to it. It is rather 951 more difficult to configure the a router to refuse to accept an IP 952 packet if that packet is an IP-within-IP tunnelled packet which is 953 going to a "wrong" place. 955 The use of MPLS also allows a VPN to span multiple SPs without 956 depending in any way on the inter-domain distribution of IPv4 routing 957 information. 959 It is also possible for a VPN user to provide himself with enhanced 960 security by making use of Tunnel Mode IPSEC [5]. This is discussed 961 in the remainder of this section. 963 9.1. Point-to-Point Security Tunnels between CE Routers 965 A security-conscious VPN user might want to ensure that some or all 966 of the packets which traverse the backbone are authenticated and/or 967 encrypted. The standard way to obtain this functionality today would 968 be to create a "security tunnel" between every pair of CE routers in 969 a VPN, using IPSEC Tunnel Mode. 971 However, the procedures described so far do not enable the CE router 972 transmitting a packet to determine the identify of the next CE router 973 that the packet will traverse. Yet that information is required in 974 order to use Tunnel Mode IPSEC. So we must extend those procedures 975 to make this information available. 977 A way to do this is suggested in [6]. Every VPN-IPv4 route can have 978 an attribute which identifies the next CE router that will be 979 traversed if that route is followed. If this information is provided 980 to all the CE routers in the VPN, standard IPSEC Tunnel Mode can be 981 used. 983 If the CE and PE are BGP peers, it is natural to present this 984 information as a BGP attribute. 986 Each CE that is to use IPSEC should also be configured with a set of 987 address prefixes, such that it is prohibited from sending insecure 988 traffic to any of those addresses. This prevents the CE from sending 989 insecure traffic if, for some reason, it fails to obtain the 990 necessary information. 992 When MPLS is used to carry packets between the two endpoints of an 993 IPSEC tunnel, the IPSEC outer header does not really perform any 994 function. It might be beneficial to develop a form of IPSEC tunnel 995 mode which allows the outer header to be omitted when MPLS is used. 997 9.2. Multi-Party Security Associations 999 Instead of setting up a security tunnel between each pair of CE 1000 routers, it may be advantageous to set up a single, multiparty 1001 security association. In such a security association, all the CE 1002 routers which are in a particular VPN would share the same security 1003 parameters (.e.g., same secret, same algorithm, etc.). Then the 1004 ingress CE wouldn't have to know which CE is the next one to receive 1005 the data, it would only have to know which VPN the data is going to. 1006 A CE which is in multiple VPNs could use different security 1007 parameters for each one, thus protecting, e.g., intranet packets from 1008 being exposed to the extranet. 1010 With such a scheme, standard Tunnel Mode IPSEC could not be used, 1011 because there is no way to fill in the IP destination address field 1012 of the "outer header". However, when MPLS is used for forwarding, 1013 there is no real need for this outer header anyway; the PE router can 1014 use MPLS to get a packet to a tunnel endpoint without even knowing 1015 the IP address of that endpoint; it only needs to see the IP 1016 destination address of the "inner header". 1018 A significant advantage of a scheme like this is that it makes 1019 routing changes (in particular, a change of egress CE for a 1020 particular address prefix) transparent to the security mechanism. 1021 This could be particularly important in the case of multi-provider 1022 VPNs, where the need to distribute information about such routing 1023 changes simply to support the security mechanisms could result in 1024 scalability issues. 1026 Another advantage is that it eliminates the need for the outer IP 1027 header, since the MPLS encapsulation performs its role. 1029 10. Quality of Service 1031 Although not the focus of this paper, Quality of Service is a key 1032 component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS 1033 capabilities can be applied to labeled packets through the use of the 1034 "experimental" bits in the shim header [10], or, where ATM is used as 1035 the backbone, through the use of ATM QoS capabilities. The traffic 1036 engineering work discussed in [1] is also directly applicable to 1037 MPLS/BGP VPNs. Traffic engineering could even be used to establish 1038 LSPs with particular QoS characteristics between particular pairs of 1039 sites, if that is desirable. Where an MPLS/BGP VPN spans multiple 1040 SPs, the architecture described in [7] may be useful. An SP may 1041 apply either intserv or diffserv capabilities to a particular VPN, as 1042 appropriate. 1044 11. Scalability 1046 We have discussed scalability issues throughout this paper. In this 1047 section, we briefly summarize the main characteristics of our model 1048 with respect to scalability. 1050 The Service Provider backbone network consists of (a) PE routers, (b) 1051 BGP Route Reflectors, (c) P routers (which are neither PE routers nor 1052 Route Reflectors), and, in the case of multi-provider VPNs, (d) 1053 ASBRs. 1055 P routers do not maintain any VPN routes. In order to properly 1056 forward VPN traffic, the P routers need only maintain routes to the 1057 PE routers and the ASBRs. The use of two levels of labeling is what 1058 makes it possible to keep the VPN routes out of the P routers. 1060 A PE router to maintains VPN routes, but only for those VPNs to which 1061 it is directly attached. 1063 Route reflectors and ASBRs can be partitioned among VPNs so that each 1064 partition carries routes for only a subset of the VPNs provided by 1065 the Service Provider. Thus no single Route Reflector or ASBR is 1066 required to maintain routes for all the VPNs. 1068 As a result, no single component within the Service Provider network 1069 has to maintain all the routes for all the VPNs. So the total 1070 capacity of the network to support increasing numbers of VPNs is not 1071 limited by the capacity of any individual component. 1073 12. Intellectual Property Considerations 1075 Cisco Systems may seek patent or other intellectual property 1076 protection for some of all of the technologies disclosed in this 1077 document. If any standards arising from this document are or become 1078 protected by one or more patents assigned to Cisco Systems, Cisco 1079 intends to disclose those patents and license them on reasonable and 1080 non-discriminatory terms. 1082 13. Acknowledgments 1084 Significant contributions to this work have been made by Ravi 1085 Chandra, Dan Tappan and Bob Thomas. 1087 14. Authors' Addresses 1089 Eric C. Rosen 1090 Cisco Systems, Inc. 1091 250 Apollo Drive 1092 Chelmsford, MA, 01824 1093 E-mail: erosen@cisco.com 1095 Yakov Rekhter 1096 Cisco Systems, Inc. 1097 170 Tasman Drive 1098 San Jose, CA, 95134 1099 E-mail: yakov@cisco.com 1101 15. References 1103 [1] Awduche, Gan, Li, Swallow, and Srinavasan, "Extensions to RSVP 1104 for Traffic Engineering", draft-swallow-mpls-rsvp-trafeng-00.txt, 1105 August 1998 1107 [2] Bates and Chandrasekaran, "BGP Route Reflection: An alternative 1108 to full mesh IBGP", RFC 1966, June 1996 1110 [3] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for 1111 BGP4", February 1998, RFC 2283 1113 [4] Gleeson, Heinanen, and Armitage, "A Framework for IP Based 1114 Virtual Private Networks", October 1998, work in progress 1116 [5] Kent and Atkinson, "Security Architecture for the Internet 1117 Protocol", July 1998, draft-ietf-ipsec-arch-sec-07.txt. 1119 [6] Li, "CPE based VPNs using MPLS", October 1998, work in progress 1121 [7] Li and Rekhter, "A Provider Architecture for Differentiated 1122 Services and Traffic Engineering (PASTE)", RFC 2430, October 1998. 1124 [8] Rekhter and Rosen, "Carrying Label Information in BGP4", August 1125 1998, work in progress 1127 [9] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching 1128 Architecture", July 1998, work in progress 1130 [10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, 1131 "MPLS Label Stack Encoding", September 1998, work in progress