idnits 2.17.1 draft-ouldbrahim-vpn-vr-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages 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: ---------------------------------------------------------------------------- -- 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 (March 2001) is 8440 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) == Missing Reference: 'VPN-RFC2547' is mentioned on line 119, but not defined ** Obsolete undefined reference: RFC 2547 (Obsoleted by RFC 4364) == Unused Reference: 'GRE-RFC1701' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'CR-LDP' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'RFC-2003' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC-2401' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'RFC-2411' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'RFC-2661' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'RFC-2685' is defined on line 734, but no explicit reference was found in the text == Unused Reference: 'VPN-INW' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'VPN-ITU' is defined on line 747, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1701 -- Possible downref: Non-RFC (?) normative reference: ref. 'CR-LDP' ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-CORE' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-BGP' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-INW' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-ITU' ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) ** Downref: Normative reference to an Informational RFC: RFC 2764 Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Provider Provisioned VPN WG Hamid Ould-Brahim 3 Internet Draft Bryan Gleeson 4 draft-ouldbrahim-vpn-vr-03.txt Gregory Wright 5 Expiration Date: September 2001 Nortel Networks 7 Timon Sloane 8 Webstacks 10 Rainer Bach 11 T-Data 13 Rick Bubenik 14 SAVVIS Communications 16 Abraham Young 17 Huawei Technologies 19 Jieyun Jessica Yu 20 Chandru Sargor 21 Cosine Communications 23 Luyuan Fang 24 AT&T 26 March 2001 28 Network based IP VPN Architecture 29 using Virtual Routers 31 Status of this Memo 32 This document is an Internet-Draft and is in full conformance with 33 all provisions of Section 10 of RFC2026 [RFC-2026]. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other documents 40 at any time. It is inappropriate to use Internet- Drafts as 41 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Abstract 48 This draft describes a network based VPN architecture using virtual 49 routers. The VPN service is built based on the virtual router (VR) 50 concept, which has exactly the same mechanisms as a physical router, 51 and therefore inherits all existing mechanisms and tools for 52 configuration, operation, accounting, and maintenance. Within a VPN 53 domain, an instance of routing is used to distribute VPN 54 reachability information among VR routers. Any routing protocol can 55 be used, and no VPN-related modifications or extensions are needed 56 to the routing protocol for achieving VPN reachability. Virtual 57 routers can be deployed in different VPN configurations, direct VR 58 to VR connectivity through layer-2 or by aggregating multiple VRs 59 into a single VR combined with IP or MPLS based tunnels. This 60 architecture accommodates different backbone deployment scenarios, 61 e.g. where the VPN service provider owns the backbone, and where the 62 VPN service provider obtains backbone service from one or more other 63 service providers. 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 67 this document are to be interpreted as described in RFC-2119. 69 Table of Contents 71 1 Introduction ........................................ 3 72 2 Virtual Router Architecture Requirements ............. 4 73 2.1 Membership .......................................... 4 74 2.2 Scalability .......................................... 4 75 2.3 Quality of Service ................................... 4 76 2.4 Auto-Discovery ....................................... 5 77 2.5 Routing .............................................. 5 78 2.5.1 Routing between PE and CE ............................ 5 79 2.5.2 Routing in the Service Provider Network .............. 5 80 2.5.3 Routing between PEs................................... 5 81 2.6 Security ............................................. 5 82 2.7 Topology ............................................. 5 83 2.8 Tunneling ............................................ 5 84 2.9 Management ........................................... 5 85 2.10 General Requirements ................................. 5 86 3 Network Reference Model .............................. 6 87 3.1 The Backbone ........................................ 7 88 4 Virtual Router Definition ............................ 7 89 5 How VPNs are built and deployed using VRs?............ 8 90 5.1 VR to VR Connectivity over layer-2 Connections........ 8 91 5.2 Virtual Router Backbone Aggregation .................. 8 92 5.2.1 Tunneling ............................................ 9 93 5.2.1.1 MPLS Tunnels ...................................... 9 94 5.2.1.2 IPSec Tunnels ..................................... 9 95 5.2.2 Routing .............................................. 10 96 5.2.3 Relationship between the VRs and the Backbone VR ..... 10 97 5.2.4 Multiple Backbones connected to a single PE .......... 10 98 6 VPN Auto-Discovery ................................... 11 99 7 VRs and Extranets .................................... 12 100 8 VPNs across Domains .................................. 12 101 9 Internet Access ...................................... 13 102 10 Carrier's Carrier Case................................ 13 103 11 Operations and Management ............................ 13 104 11.1 Backbone Migration ................................... 14 105 11.2 Troubleshooting ...................................... 14 106 12 Quality of Service ................................... 14 107 13 Scalability .......................................... 15 108 14 Security Considerations .............................. 15 109 15 References............................................ 15 110 16 Acknowledgments ..................................... 16 111 17 Authors' Addresses .................................. 16 113 1. Introduction 115 Several solutions have been put forward to achieve different levels 116 of network privacy when building VPNs across a shared IP backbone. 117 Most of these solutions require separate per VPN forwarding 118 capabilities and make use of IP or MPLS based tunnels across the 119 backbone [VPN-RFC2764], [VPN-CORE], and [VPN-RFC2547]. 120 This document describes a network based VPN architecture using 121 virtual routers. The architecture complies with the IP VPN framework 122 described in [VPN-RFC2764]. The objective is to provide per VPN 123 based routing, forwarding, quality of service, and service 124 management capabilities. The VPN service is built based on the 125 virtual router concept, which has exactly the same mechanisms as a 126 physical router, and therefore inherits all existing mechanisms and 127 tools for configuration, deployment, operation, troubleshooting, 128 monitoring, and accounting. Virtual routers can be deployed in 129 different VPN configurations, direct VR to VR connectivity through 130 layer-2 links/tunnels or by aggregating multiple VRs into a single 131 VR combined with IP or MPLS based tunnels. This architecture 132 accommodates different backbone deployment scenarios, e.g. where the 133 VPN service provider owns the backbone, and where the VPN service 134 provider obtains backbone service from one or more other service 135 providers. 137 Within a VPN domain, an instance of routing is used to distribute 138 VPN reachability information among VR routers. Any routing protocol 139 can be used, and no VPN-related modifications or extensions are 140 needed to the routing protocol for achieving VPN reachability. 141 VPN reachability information to and from customer sites can be 142 dynamically learned from the CE using standard routing protocols or 143 it can be statically provisioned on the VR. The routing protocol 144 between the virtual routers and CEs is independent of the routing 145 used in the VPN backbone. The routing protocol between the VRs maybe 146 the same or it might be different than the routing mechanism used 147 between the CE and VR. 149 There are two fundamental architectures for implementing network 150 based VPNs, virtual routers (VR) and piggybacking. The main 151 difference between the two architectures resides in the model used 152 to achieve VPN reachability and membership functions. In the VR 153 model, each VR in the VPN domain is running an instance of routing 154 protocol responsible to disseminate VPN reachability information 155 between VRs. Therefore, VPN membership and VPN reachability are 156 treated as separate functions, and separate mechanisms are used to 157 implement these functions. VPN reachability is carried out by a per- 158 VPN instance of routing, and a range of mechanisms is possible for 159 determining membership (see section 6.0). In the piggyback model the 160 VPN network layer is terminated at the edge of the backbone, and a 161 backbone routing protocol (i.e. BGP-4) is responsible for 162 disseminating the VPN membership and reachability information 163 between provider edge routers (PE) for all the VPNs configured on 164 the PE. [VPN-RFC2547bis] is an example of a piggyback VPN 165 architecture. 167 2. Virtual Router Architecture Requirements 169 This section lists some requirements addressed by the proposed VR 170 architecture. 172 2.1 Membership 174 All virtual routers that are members of a specific VPN MUST share 175 the same VPN-ID. A recommended VPN identifier (VPN-ID) format to be 176 used is defined in the standard RFC2685. 178 2.2 Scalability 180 In this architecture, the backbone internal nodes are not required 181 to be VPN aware or VR aware, and therefore they don't keep any VPN 182 state within the backbone. However, in the case where the internal 183 nodes are also VR aware then it is possible to have either tunnels 184 from the PE or the CE connecting to the internal VRs. This type of 185 VPN deployment can be useful when the internal nodes are 186 geographically suitable to be the VPN hub. 188 2.3 Quality of Service 190 Existing quality of service mechanisms developed for physical 191 routers should all be available to be used per VR basis. Therefore, 192 quality of service (policing/shaping/classification/scheduling) 193 SHOULD be configurable per VPN basis. 195 2.4 Auto-discovery 197 It should be possible for the VRs to automatically discover each 198 other, setup tunnels to each other, and exchange private routing 199 information across the backbone. It is required that the auto- 200 discovery mechanism take into consideration of the case where the 201 VPNs are implemented across domains. We assume in this document that 202 BGP as described in [VPN-BGP] is used as the mechanism to distribute 203 membership, topology, and tunnel information among VRs members of 204 the same VPN. 206 2.5 Routing 208 2.5.1 Routing between PE and CE 210 Any existing routing protocol in the VPN domain can be used between 211 PE and the CE. 213 2.5.2 Routing in the Service Provider Network (Backbone) 215 The choice of the backbone routing protocol should not be 216 constrained by the VPNs. 218 2.5.3 Routing between PEs 220 Any existing routing protocol in the VPN domain can be used between 221 PEs. 223 2.6 Security 225 The architecture MUST accommodate different levels of data and 226 routing security. The architecture must provide authentication and 227 encryption services for VPNs requiring strong security capabilities. 229 2.7 Topology 231 VPN topologies like a hub and spoke, and full mesh MUST be 232 supported. Furthermore, it should be possible to build arbitrary VPN 233 topologies. 235 2.8 Tunneling 237 The architecture should not be limited to a single tunneling 238 mechanism. It should be possible to use per VPN basis, IPSec, GRE, 239 IP in IP, and MPLS tunnels, as it should also be possible to support 240 shared tunnels between VPNs. Therefore within a single VPN, 241 different type of tunnels can be used. 243 2.9 Management 245 It should be easy to configure, deploy, operate and troubleshoot 246 each VPN independently using existing mechanisms and tools. Tools 247 used for operating, managing and debugging IP networks can continue 248 to be used without any modification. 250 2.10 General Requirements 251 The followings are some general requirements for the VR 252 architecture: 253 (a) The architecture should accommodate different sizes of VPNs, 254 and one VPN should not impact other VPNs on the PE. 255 (b) The architecture MUST support overlapping VPN address spaces 256 in separate VPNs. 257 (c) The architecture should support direct paths between VPN 258 sites that bypass the service provider backbone (backdoor 259 links). Traffic can be directed to the backdoor link, or 260 injected to the backbone with the flexibility of using both 261 the backbone access, and the backdoor link as internal or 262 external paths. 263 (d) The architecture MUST work over different deployment 264 scenarios, e.g. where the service provider owns their own 265 backbone, and where the service provider obtains backbone 266 service from one or more other service providers. 268 3. Network Reference Model 270 A VPN customer site is connected to the provider backbone by means 271 of a connection between a CE device, (which can either be a bridge 272 or a router) and a virtual router. CE devices are preconfigured to 273 connect to one (or more) VR(s).Multiple virtual routers 274 coexist on the same service provider edge device (PE). 275 CE devices can be attached to VRs over any type of access link (e.g. 276 ATM, frame relay, ethernet, PPP or IP tunneling mechanism such as 277 IPSec, L2TP or GRE tunnels). 279 +---+ +---+ 280 | P |....| P | 281 +---+ +---+ 282 PE / \ PE 283 +----+ +------+ +------+ +---+ 284 | CEs|--|-{VRs}| |{VRs}-|--|CEs| 285 +----+ +------+ +------+ +---+ 286 \ / 287 +---+ +---+ 288 | P |....| P | 289 +---+ +---+ 291 Figure 1: Network Reference Model 293 CE sites can be statically connected to the provider network via 294 dedicated circuits, or can use dial-up links. Routing tables 295 associated with each virtual router define the site-to-site 296 reachability for each VPN. The internal backbone provider routers 297 (P) are not VPN aware and do not keep VPN state. 299 3.1 Backbone 300 In general the backbone is a shared network infrastructure, which 301 represents: 303 (a) A layer-2 ATM or frame relay network. 304 (b) An IP network. 305 (c) An MPLS network. 307 Not all VPNs existing on the same PE are necessarily connected to 308 the same backbone. The same backbone can be built from multiple 309 transport technologies. 311 4. Virtual Router Definition 313 A virtual router (VR) is an emulation of a physical router at the 314 software and hardware levels. Virtual routers have independent IP 315 routing and forwarding tables and they are isolated from each other. 316 This means that a VPN's addressing space can overlap with another 317 VPN's address space. The addresses need only be unique within a VPN 318 domain. 320 A virtual router has two main functions: 322 1. Constructing routing tables describing the paths between VPN 323 sites using any routing technologies (e.g., static, OSPF, RIP, 324 or BGP). 325 2. Forwarding packets to the next hops within the VPN domain. 327 From the VPN user point of view, a virtual router provides the same 328 functionality as a physical router. Separate routing, and forwarding 329 capabilities provide each VPN CE link with the appearance of a 330 dedicated router that guarantees isolation from other VPN traffic 331 while running on shared forwarding and transmission resources. 332 Virtual routers belonging to the same VPN domain must have the same 333 Virtual Private Network Identifier (VPNID). An example of VPNID 334 format is described in [VPN-RFC2685]. To the CE access device, the 335 virtual router appears as a neighbor router in the CE based network, 336 to which it sends all traffic for non-local VPN destinations. Each 337 CE access device must learn the set of destinations reachable 338 through its connection to the virtual router; this may be as simple 339 as a default route. Virtual routers participating in a single VPN 340 domain are responsible for learning and disseminating VPN 341 reachability information among themselves. A given virtual router 342 holds the routes only for the specific VPNs configured for that VR. 343 Any routing protocol can be used between the VRs and the CEs. 345 5. How VPNs are built and deployed using VRs? 347 Two main VR deployment scenarios can be used for building virtual 348 private networks: 349 - VR to VR connectivity over a layer 2 connections. 350 - Aggregating multiple virtual routers over a single virtual router. 352 The above VR deployment scenarios can coexist on a single PE and 353 they are not mutually exclusive. 355 5.1 VR to VR Connectivity over Layer 2 Connections 357 As illustrated in figure 2, virtual routers can be deployed over 358 direct layer-2 frame relay or ATM connections or other layer-2 359 transport technology. 361 PE PE 362 +---------------+ +---------------+ 363 +-----+ | | | | +-----+ 364 |VPN-A| | +----+ Layer-2 connections +----+ | |VPN-A| 365 |sites| | |VR-A|<---------------------------->|VR-A| | |sites| 366 +-----+ | +----+ | -------- | +----+ | +-----+ 367 | |-( Layer-2)-| | 368 +-----+ | +----+ | (Backbone) | +----+ | +-----+ 369 |VPN-B|-|-|VR-B| | -------- | |VR-B|-|-|VPN-B| 370 |sites| | +----+<--------------------|------->+----+ | |sites| 371 +-----+ | | | | +-----+ 372 +---------------+ +---------------+ 374 Figure 2: VR to VR connectivity over a layer-2 backbone 376 This type of VR deployment allows direct quality of service 377 engineering per VPN connection basis. The connections can be 378 statically configured or dynamically established. 380 5.2 Virtual Router Backbone Aggregation 382 Another typical VPN configuration consists of connecting multiple 383 virtual routers to the backbone through the use of a single virtual 384 router (figure 3). For easy reference in the following sections 385 let's call this single virtual router "the backbone virtual router" 386 or "the backbone VR". 388 The backbone virtual router is not functionally different than other 389 virtual routers. It is only a virtual router that is configured and 390 deployed in a special configuration. 392 PE PE 393 +---------------+ +---------------+ 394 +-----+ | | | | +-----+ 395 |VPN-A| | +----+ MPLS/IP based Tunnels +----+ | |VPN-A| 396 |sites|-|-|VR-A|\.......|<---------->|........|VR-A|-|-|sites| 397 +-----+ | +----+ +----+ --------- | +----+/+----+ | +-----+ 398 | |VR-1|-|-(IP/MPLS )-|-|VR-2| | 399 +-----+ | +----+/+----+ |(Backbones) | +----+\+----+ | +-----+ 400 |VPN-B|-|-|VR-B| | --------- | |VR-B|-|-|VPN-B| 401 |sites| | +----+........|<---------->|........+----+ | |sites| 402 +-----+ | MPLS/IP based Tunnels | +-----+ 403 | | | | 404 +---------------+ +---------------+ 406 Figure 3: VR-1 and VR-2 used as backbone VRs 408 The backbone virtual router connects each PE to a shared backbone 409 infrastructure. Backbone virtual routers can be deployed over ATM, 410 FR, IP, or MPLS networks. Since the backbone VR allows the 411 aggregation of VPN VRs, backbone configuration remains unaffected as 412 new VPN sites are added. The relationship between the VRs and the 413 backbone VR is an overlay relationship. 415 5.2.1 Tunneling 417 VPN data and routing information is tunneled through the use of IP 418 or MPLS based tunnels (e.g., IPSec, GRE, IP in IP, MPLS). Depending 419 on the tunnel technology used, the tunnels can be statically 420 configured or dynamically established. The tunnel appears to VRs as 421 a point-to-point link. Traffic sent through the tunnel, and 422 forwarded by the backbone VR is opaque to the underlying backbone 423 technology used. 425 A tunnel can be established per VPN or shared among many VPNs (VRs). 426 The tunnel can originate from the backbone virtual router or from 427 the VRs. 429 The backbone VR makes it appear as if each VR within a VPN is 430 directly connected (full and partial mesh configurations supported). 431 Each VR within the VPN exchanges routing information directly with 432 the other VRs in the VPN. 433 VPNs may use different type of tunnels for inter-VR connectivity. 434 Indeed, Two sites may use MPLS as their tunnel technology of choice. 435 Other sites (which transit through not fully secured domains) may 436 choose to use IPSec. 438 5.2.1.1 MPLS Tunnels 440 MPLS tunneling can be used in different forwarding scenarios. Two 441 labels hierarchy can be used. One simple forwarding scenario is the 442 inner label identifies the VR intended to receive the private packet 443 (to be forwarded to the CE). Another forwarding scenario is to 444 distribute the inner label per VPN basis across the tunnel. In this 445 case the label distribution process can be achieved using BGP or 446 existing label distribution protocol per VPN basis. The inner label 447 relates to the private VPN prefix. The label and reachability 448 distribution is done through the tunnels. On the egress side traffic 449 will be directed to the egress interface by looking up the inner 450 label. 452 5.2.1.2 IPSec Tunnels 454 IPSec is needed when there is a requirement for strong encryption or 455 strong authentication. It also supports multiplexing and a 456 signalling protocol - IKE. IPSec tunnels can be established between 457 two VPNs across the backbone (originating from the backbone VRs). 459 5.2.2 Routing 461 The backbone VR exchanges routing information with other backbone 462 entities (P routers and possibly other backbone VRs). 463 Virtual routers can run any routing protocol on their local VPN 464 domain. Both static routes and dynamic routing protocols such as 465 RIP, OSPF, and BGP-4 can be used. VPN sites exchange routing 466 information through the tunnels over the backbone. 468 If a backdoor link is used between private CE based network running 469 any IGP, then by adjusting the backdoor link costs appropriately, 470 the backbone link can be favored for forwarding VPN traffic. By 471 lowering the weight, the backdoor link can be used as a backup link 472 in case the backbone path fails. 474 5.2.3 Relationship between the VRs and the Backbone VR 476 The routing domain of a set of VRs participating in a single VPN has 477 no relation to the routing domain of the backbone VR. The backbone 478 VR is not necessarily aware of the routing instances running on each 479 private virtual router. However, because the backbone VR is also a 480 virtual router, it can build routing relationships with other VRs if 481 needed. 483 5.2.4 Multiple Backbones connected to a single PE 485 Figure 4 illustrates an example where multiple backbones are 486 connected to the same PE. This type of configuration can be used 487 when the PE is connected to multiple service provider backbones, or 488 when the service provider offers different VPN services for 489 different type of backbones. 491 PE PE 492 +---------------+ +---------------+ 493 +-----+ | | | | +-----+ 494 |VPN-A| | +----+ | | +----+ | |VPN-A| 495 |sites| | |VR-A|\ | | |VR-A| | |sites| 496 +-----+ | +----+ +----+ | --------- | +----+/+----+ | +-----+ 497 | |VR-1|-|-(Backbones)|-|VR-2| | 498 +-----+ | +----+/+----+ | ( 1 )| +----+\+----+ | 499 |VPN-B|-|-|VR-B| | --------- | |VR-B|-|-|VPN-B| 500 |sites| | +----+ | | +----+ | |sites| 501 +-----+ | | | | +-----+ 502 | | | | 503 +-----+ | | | | +-----+ 504 |VPN-C| | +----+ | | +----+ | |VPN-C| 505 |sites|-|-|VR C| | | |VR-C|-|-|sites| 506 +-----+ | +----+\+----+ | -------- | +----+/+----+ | +-----+ 507 | |VR-3|-|-(Backbone)-|-|VR-4| | 508 +-----+ | +----+/+----+ | ( 2 & 3 ) | +----+\+----+ | +-----+ 509 |VPN-D|-|-|VR-D| | -------- | |VR-D|-|-|VPN-D| 510 |sites| | +----+ | | +----+ | |sites| 511 +-----+ | | | | +-----+ 512 +---------------+ +---------------+ 514 Figure 4: Multiple Backbones connected to a single PE 516 6. VPN Auto-Discovery 518 The virtual router approach explicitly separates the mechanisms used 519 for distributing reachability information from mechanisms used for 520 distributing VPN topology and membership information. VPN membership 521 information refers to the set of PEs that have customers in a 522 particular VPN. VPN topology represents the set of PEs and their 523 interconnectivity within the VPN. The topology can be a full-mesh of 524 PEs, a hub and spoke, or anything in between. Dynamic topology can 525 also be handled due to on-demand VPN customers. 527 VPN discovery can be achieved through different mechanisms, for 528 example: 530 - Directory server approach, which VRs query a server to determine 531 their neighbors. 532 - Explicit configuration via a management platform. 533 - Piggybacking VPN membership and topology information using 534 existing routing protocols (e.g., BGP) [VPN-BGP]. 536 The above mechanisms can be combined on a single PE. As an example, 537 for some VPNs topology discovery is done only through a management 538 platform. For others, dynamic topology discovery is achieved using 539 existing routing protocol. 541 In this document it is assumed that BGP is used as the mechanism for 542 achieving auto-discovery of VPN members. As described in [VPN-BGP], 543 VR addresses are exchanged, along with the information needed to 544 enable the PEs to determine which VRs are in the same VPN 545 ("membership"), and which of those VRs are to have VPN connectivity 546 ("topology"). Once the VRs are reachable through the tunnels, routes 547 ("reachability") are then exchanged by running existing routing 548 protocol per VPN basis (across the tunnels). 550 It is important to note that, for the VR architecture, the auto- 551 discovery mechanism is only used to automatically exchange control 552 VPN information between VRs. It is not intended for piggybacking vpn 553 private reachability information onto the backbone routing instance. 555 7. VRs and Extranets 557 Extranets are commonly used to refer to a scenario whereby two or 558 more companies have network access to a limited amount of each 559 other's corporate data. An important feature of extranets is the 560 control of who can access what data, and this is essentially a 561 policy decision. Policy decisions are enforced at the 562 interconnection points between different domains [VPN-RFC2764]. The 563 enforcement may be done via a firewall, router with access list 564 functionality, or any device capable of applying policy decision to 565 transit traffic. 567 In the VR architecture, policy can be enforced between two VPNs, or 568 between a VPN and the Internet, in exactly the same manner as is 569 done today without VPNs. For example, two VRs (VPNs) could be 570 interconnected, which each VR locally imposing its own policy 571 controls, via a firewall, on all traffic that enters its VPN from 572 the outside (whether from another VR or from the Internet). 573 Combining firewalls and exchanging private routes between VRs 574 (members of different VPNs) provide a flexible mechanism to build 575 different flavors of extranets. 577 8. VPNs across Domains 579 It is possible that a VPN may cross multiple domains administered by 580 different service providers. In the VR model, tunnels are used to 581 provide intra-VR connectivity across the backbones. The main 582 requirement on the service provider in order to achieve end-to-end 583 across domains VPN connectivity is the ability for both domains to 584 support a common tunnel technology to be used. Once the tunnel is 585 established, private data (e.g., routing information, and private 586 customer data) can flow from one domain to the other with the same 587 level of security as provided in a single service provider network. 588 Another possible scenario is to use two virtual routers configured 589 on each PE at the interconnection point. Each VR will use policy 590 decisions and firewalling to control VPN traffic transiting from one 591 domain to the other. 593 The ability to use the standard VPN-ID format allows also 594 unambiguous VPN identification across domains. 596 9. Internet Access 598 The same link attaching to the VR can be used to provide the 599 internet access to the VPN sites. The VR operations are decoupled 600 from the mechanisms used by the customer sites to access the 601 internet. 603 One way of providing VPN internet access is to have the PE/backbone- 604 VR steering private traffic to the VR, and internet to normal 605 backbone/internet forwarding table. PE/backbone VR can hold the 606 internet routes (not necessarily the VRs). Firewalls need to be used 607 to secure the access (with the ability to use NAT). 609 Other options are also valid. One may want to have a particular VR 610 handling internet access only (rather than going to the backbone 611 VR), or a default route to the internet gateway can be used. 613 10. Carrier's Carriers Case 615 It is possible that a VPN service is also a network of a service 616 provider offering VPN services. Different options can be used to 617 implement the VPN hierarchy. Either tunnels are built from the VPN 618 edges to the CEs, and the VRs are transparently providing VPN 619 service to the remote CEs. This can be useful in the case where the 620 CEs are themselves VRs and the service provider is also outsourcing 621 the management of his customer VPN services. Another case is the 622 remote VPN services are completely transparent to the VRs (on the 623 PEs). This is the default case. It is up to the VPN network to 624 distribute VPN reachability across the CEs. Another option is for 625 the VPN service to implement the VR architecture. In this option, 626 the VPN Backbone VRs appear as CEs to the VRs configured on the PEs. 628 11. Operations and Management 630 One of the greatest strengths of the VR approach to VPN creation is 631 that all the existing tools for operating, managing and debugging IP 632 networks can continue to be used without modification. All the 633 standard MIBs, such as the forwarding/route table and interface MIBs 634 are available. 635 In case of PE failure (e.g. migration, upgrades, etc.), the service 636 provider may want to control and decide what VPN services gets 637 reestablished first. This particular point is important when a large 638 number of VPNs is supported on the PE where each VPN service has 639 different service availability requirements. 641 Since each VR operates as an independent router, it is possible for 642 the management of the VRs to be outsourced. VPN customers may 643 choose to configure (or perhaps only to monitor) the VRs that make 644 up their VPN. It is also possible that the backbone VRs could be 645 managed by a separate entity. Each VR operates independently, and 646 can be individually reconfigured without effecting other VRs on the 647 same PE. In some implementations, it may even be possible for a VR 648 to be "rebooted" by a customer without affecting other VRs. It is 649 not required for a given VR implementation to support all management 650 capabilities described in this section. 652 11.1 Backbone Migration 654 One benefit in using multiple backbone virtual routers is the 655 ability for the backbone network administrator to migrate its 656 backbone from one core technology to another with minimal disruption 657 to VPN services. Indeed a VPN configuration change or a VPN-software 658 upgrade is totally transparent to the backbone protocol and policies 659 (this is due to decoupling the VPN routing protocol from the 660 provider backbone routing protocol). 662 11.2 Troubleshooting 664 The service provider or the VPN customer can use all existing 665 troubleshooting tools per VPN basis (e.g. ping and traceroute). As 666 an example a VPN customer can telnet to its own VR and performs some 667 troubleshooting operations. In this particular case, the service 668 provider can configure for each VPN customer restricted privileges 669 over the virtual router associated with the customer VPN network. 670 However, backbone topology information is completely hidden to the 671 VPN VR, and therefore to the service provider customer. 673 12. Quality of Service 675 This architecture can utilize different quality of service 676 mechanisms. QoS mechanisms developed for physical routers can be 677 used with VRs, on a per-VR basis. e.g. classification, policing, 678 drop policies, traffic shaping and scheduling/bandwidth reservation. 679 The architecture allows separate quality of service engineering of 680 the VPNs and the backbone. 682 13. Scalability 684 Only the PEs are handling the VPN type information. The internal 685 backbone routers (the P routers) are not VPN aware. Furthermore, 686 virtual routers allow multiple privates CE based networks to connect 687 to a single PE. 689 One advantage of the ability to contain the VPN address space and 690 VPN routing and forwarding capabilities within the virtual router 691 entity is the possibility to distribute PE system resources per VPN 692 basis. Indeed, as an example, different scheduling mechanisms can be 693 used for processing each VPN activity within the PE. This type of 694 per VPN resource management contributes in establishing a wide range 695 of priority schemes among VPNs within the PE. 697 14. Security Considerations 699 Different levels of data, routing and configuration security can be 700 implemented. Any existing security related mechanisms supported by 701 existing routing protocols (e.g. authentication) can be used 702 unmodified in the VR architecture. If IPSec tunneling is used as the 703 tunneling protocol, then both the control and data traffic that 704 travels over the tunnel can be secured; so that routing specific 705 security enhancements are not needed. Any private routing, 706 forwarding and addressing manipulation are done within the virtual 707 router context. Direct layer-2 connections (ATM, FR), or specific 708 tunneling mechanisms can also provide different levels of data 709 security. 711 15. References 713 [GRE-RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, 714 "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. 716 [CR-LDP] Jamoussi, B., et al, "Constraint-based LSP Setup using 717 LDP", Work in Progress. 719 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 720 October 1996. 722 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 723 3", RFC 2026, October 1996. 725 [RFC-2401] Kent S., Atkinson R., "Security Architecture for the 726 Internet Protocol", RFC2401, November 1998. 728 [RFC-2411] Thayer, R., et al, "IP Security Document Roadmap", RFC 729 2411, November 1998. 731 [RFC-2661] Townsley, W., et al, "Layer Two Tunneling Protocol L2TP", 732 RFC2661, August 1999. 734 [RFC-2685] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", RFC 2119, March 1997. 737 [VPN-CORE] Muthukrishnan, K., Malis, A., "Core MPLS IP VPN 738 Architecture", Work in Progress 740 [VPN-BGP] Ould-Brahim, H., et al., "Using BGP as an Auto-Discovery 741 Mechanism for Network-based VPNs", work in progress, November 742 2000. 744 [VPN-INW] Sumimoto, J., et al, "MPLS VPN Interworking", Work in 745 Progress. 747 [VPN-ITU] "Draft Recommendation Y.IPVPN", Study Group 13, Q20/13, 748 May 2000. 750 [VPN-RFC2547bis] Rosen E., et al, "BGP/MPLS VPNs", work in progress. 752 [VPN-RFC2685] Fox B., et al, "Virtual Private Networks Identifier", 753 RFC 2685, September 1999. 755 [VPN-RFC2764] Gleeson, B., et al., "A Framework for IP Based Virtual 756 Private Networks", RFC 2764, February 2000. 758 16. Acknowledgments 760 The authors would like to acknowledge the following individuals for 761 their helpful comments and suggestions: Bilel Jamoussi, David 762 Hudson, David Drynan, Ru Wadasinghe, Scott Larrigan, Peter Ashwood- 763 Smith, Martin Pepin, Ahmad Khalid, Don Fedyk, Keereti Melkote, Ron 764 Bonica, Jerry Sydir, and Mark Duffy. 766 17. Author's Addresses 768 Hamid Ould-Brahim Bryan Gleeson 769 Nortel Networks Nortel Networks 770 P O Box 3511 Station C 2305 Mission College Blvd 771 Ottawa, ON K1Y 4H7 Santa Clara CA 95054 772 Canada USA 774 Phone: +1 (613) 765 3418 Phone: +1 (408) 565 2625 775 Email: hbrahim@nortelnetworks.com Email:bgleeson@shastanets.com 777 Gregory Wright Timon Sloane 778 Nortel Networks Webstacks 779 P O Box 3511 Station C 444 Oakmead Parkway 780 Ottawa, ON K1Y 4H7 Sunnyvale, CA 94085 781 Canada USA 783 Phone: +1 (613) 765 7912 Phone: +1 408-524-8484 784 Email: gwright@nortelnetworks.com Email:timon@webstacksinc.com 786 Rainer Bach Rick Bubenik, 787 T-Data SAVVIS Communications 788 Hans-Guenther-Sohl-Strasse7 717 Office Parkway 789 40235, Duesseldorf St. Louis, Mo. 63141 790 Germany USA 792 Phone: 49 211 694 2420 Phone: +1 (314) 468-7021 793 Email: Rainer.Bach@telekom.de rickb@savvis.net 795 Abraham Young Jieyun Jessica Yu 796 HUAWEI Technologies Co., LTD. Cosine Communications 797 Kefa Road 1200 Bridge Parkway 798 Science-Based Industrial Park Redwood City CA 94065 799 Nanshan District, Shenzhen 518057 CA 94065 800 China USA 802 Phone: +86-755-6543662 Phone: +1 (650) 628-4881 803 Email: abyoung@huawei.com.cn Email: jyy@cosinecom.com 805 Chandru Sargor 806 Cosine Communications 807 1200 Bridge Parkway 808 Redwood City 809 CA 94065 810 USA 811 Phone: +1 (650) 637-2416 812 Email: Chandramouli.Sargor@cosinecom.com 814 Luyuan Fang 815 AT&T 816 200 Laurel Avenue 817 Middletown, NJ 07748 819 Phone: +1 (732) 420-1921 820 Email: Luyuanfang@att.com 821 Full Copyright Statement 822 "Copyright (C) The Internet Society (date). All Rights Reserved. 823 This document and translations of it may be copied and furnished to 824 others, and derivative works that comment on or otherwise explain it 825 or assist in its implementation may be prepared, copied, published 826 and distributed, in whole or in part, without restriction of any 827 kind, provided that the above copyright notice and this paragraph 828 are included on all such copies and derivative works. However, this 829 removing the copyright notice or references to the Internet Society 830 or other Internet organizations, except as needed for the purpose of 831 developing Internet standards in which case the procedures for 832 copyrights defined in the Internet Standards process must be 833 followed, or as required to translate it into languages other than 834 English. 835 The limited permissions granted above are perpetual and will not be 836 revoked by the Internet Society or its successors or assigns. 837 This document and the information contained herein is provided on an 838 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 839 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 840 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 841 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 842 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.