idnits 2.17.00 (12 Aug 2021) /tmp/idnits16923/draft-ietf-ppvpn-rfc2917bis-00.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 Abstract section. ** 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.) ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 559 has weird spacing: '...ithm is f(X,Y...' == Line 591 has weird spacing: '...HQs and small...' -- 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 (July 2001) is 7615 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 section? 'Rosen1' on line 675 looks like a reference -- Missing reference section? 'Rosen2' on line 677 looks like a reference -- Missing reference section? 'Callon' on line 668 looks like a reference -- Missing reference section? 'Fox' on line 671 looks like a reference -- Missing reference section? 'Meyer' on line 673 looks like a reference -- Missing reference section? 'VPN-FRAME' on line 683 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Karthik Muthukrishnan 3 INTERNET-DRAFT Chandrasekar Kathirvelu 4 Tom Walsh 5 Expires January 2002 Lucent Technologies 7 Andrew Malis Fred Ammann 8 Vivace Networks, Inc. COMMCARE telecommunications 10 Jing Ming Xiao Junichi Sumimoto 11 China UNICOM NTT Information Sharing Platform Labs 13 July 2001 15 A Core MPLS IP VPN Architecture 17 19 1. Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference 32 material or to cite them other than as "work in progress." 34 This draft is not a product of any working group and was written and 35 presented to the IETF well before the formation of any working group 36 related to Core VPNs. 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Abstract This memo presents an approach for building core Virtual 45 Private Network (VPN) services in a service provider's MPLS backbone. 46 This approach uses Multiprotocol Label Switching (MPLS) running in 47 the backbone to provide premium services in addition to best effort 48 services. The central vision is for the service provider to provide a 49 virtual router service to their customers. The keystones of this 50 architecture are ease of configuration, user security, network 51 security, dynamic neighbor discovery, scaling and the use of existing 52 routing protocols as they exist today without any modifications. 54 1.0. Acronyms 56 ARP Address Resolution Protocol 57 CE Customer Edge router 58 LSP Label Switched Path 59 PNA Private Network Administrator 60 SLA Service Level Agreement 61 SP Service Provider 62 PE Service Provider Edge Device 63 SPNA SP Network Administrator 64 VMA VPN Multicast Address 65 VPNID VPN Identifier 66 VR Virtual Router 67 VRC Virtual Router Console 68 P Provider Device 69 DSCP DiffServ Code Point 70 OUI Organizationally Unique Identifier 72 2.0. Introduction 74 This draft describes an approach for building IP VPN services out 75 of the backbone of the SP's network. Broadly speaking, two 76 possible approaches present themselves: the piggyback model and 77 the virtual router approach. The piggyback model is based on 78 overloading some semantic(s) of existing routing protocols to 79 carry reachability information. In this document, we focus on the 80 virtual router service. 82 The approach presented here does not depend on any modifications 83 of any existing routing protocols. This draft makes a concerted 84 effort to draw the line between the SP and the PNA: the SP owns 85 and manages layer 1 and layer 2 services while layer 3 services 86 belong to and are manageable by the PNA. By the provisioning of 87 fully logically independent routing domains, the PNA has been 88 given the flexibility to use private and unregistered addresses. 89 Due to the use of private LSPs and the use of VPNID encapsulation 90 using label stacks over shared LSPs, data security is not an 91 issue. 93 The approach espoused in this draft differs from that described in 94 [Rosen1] in that no specific routing protocol has been overloaded 95 to carry VPN routes. [Rosen1] specifies a way to modify BGP to 96 carry VPN unicast routes across the SP's backbone. To carry 97 multicast routes, further architectural work will be necessary. 99 3.0. Virtual Routers 101 A virtual router is a collection of threads, either static or 102 dynamic, in a routing device, that provides routing and forwarding 103 services much like physical routers. A virtual router need not be 104 a separate operating system process (although it could be); it 105 simply has to provide the illusion that a dedicated router is 106 available to satisfy the needs of the network(s) to which it is 107 connected. A virtual router, like its physical counterpart, is an 108 element in a IP domain. The other routers in this domain could be 109 physical or virtual routers themselves. Given that the virtual 110 router connects to a specific (logically discrete) routing domain 111 and that a physical router can support multiple virtual routers, 112 it follows that a physical router supports multiple (logically 113 discreet) routing domains. 115 From the user (VPN customer) standpoint, it is imperative that the 116 virtual router be as equivalent to a physical router as possible. 117 In other words, with very minor and very few exceptions, the 118 virtual router should appear for all purposes (configuration, 119 management, monitoring and troubleshooting) like a dedicated 120 physical router. The main motivation behind this requirement is to 121 avoid upgrading or re-configuring the large installed base of 122 routers and to avoid retraining of network administrators. 124 The aspects of a router that a virtual router needs to emulate 125 are: 127 - Configuration of any combination of routing protocols 129 - Transport of Unicast and Multicast IP traffic with 130 differentiated or with absolute Qos. 132 - Monitoring of the network 134 - Troubleshooting. 136 Every VPN has a logically independent routing domain. This 137 enhances the SP's ability to offer a fully flexible virtual router 138 service that can fully serve the SP's customer without requiring 139 physical per-VPN routers. This means that the SP's "hardware" 140 investments, namely routers and links between them, can be re-used 141 by multiple customers. 143 4.0. Objectives 145 4.1. Easy, scaleable configuration of VPN endpoints in the service 146 provider network. At most, one piece of configuration should be 147 necessary when a CE is added. 149 4.2. No use of SP resources that are globally unique and hard to 150 get such as IP addresses and subnets. 152 4.3. Dynamic discovery of VRs (Virtual Routers) in the SP's cloud. 153 This is an optional, but extremely valuable "keep it simple" goal. 155 4.4. Virtual Routers should be fully configurable and monitorable 156 by the VPN network administrator. This provides the PNA with the 157 flexibility to either configure the VPN themselves or outsource 158 configuration tasks to the SP. 160 4.5. Quality of data forwarding should be configurable on a VPN- 161 by-VPN basis. This should translate to continuous (but perhaps 162 discrete) grades of service. Some examples include best effort, 163 dedicated bandwidth, QOS, and policy based forwarding services. 165 4.6. Differentiated services should be configurable on a VPN-by- 166 VPN basis, perhaps based on LSPs set up for exclusive use for 167 forwarding data traffic in the VPN. 169 4.7. Security of internet routers extended to virtual routers. 170 This means that the virtual router's data forwarding and routing 171 functions should be as secure as a dedicated, private physical 172 router. There should be no unintended leak of information (user 173 data and reachability information) from one routing domain to 174 another. 176 4.8. Specific routing protocols should not be mandated between 177 virtual routers. This is critical to ensuring the VPN customer can 178 setup the network and policies as the customer sees fit. For 179 example, some protocols are strong in filtering, while others are 180 strong in traffic engineering. The VPN customer might want to 181 exploit both to achieve "best of breed" network quality. 183 4.9. No special extensions to existing routing protocols such as 184 BGP, RIP, OSPF, ISIS etc. This is critical to allowing the future 185 addition of other services such as NHRP and multicast. In 186 addition, as advances and addenda are made to existing protocols 187 (such as traffic engineering extensions to ISIS and OSPF), they 188 can be easily incorporated into the VPN implementation. 190 5.0. Architectural Outline 192 5.1. Every VPN is assigned a VPNID which is unique within the SP's 193 network.i.e., local to the SP's network. 195 By definition there can be different VPNIDs for the same OUI in 196 different VPN clouds. 198 These different VPN Clouds are separated by one or more IP/MPLS 199 links. 201 This identifier unambiguously identifies the VPN with which a 202 packet or connection is associated. The VPNID of zero is reserved; 203 it is associated with and represents the public internet. 205 5.2. The VPN service is offered in the form of a Virtual Router 206 service. These VRs reside in the PE and are as such confined to 207 the edge of the SP's cloud. The VRs will use the SP's network for 208 data and control packet forwarding but are otherwise invisible 209 outside the PEs. 211 5.3. The "size" of the VR contracted to the VPN in a given PE is 212 expressed by the quantity of IP resources such as routing 213 interfaces, route filters, routing entries etc. This is entirely 214 under the control of the SP and provides the fine granularity that 215 the SP requires to offer virtually infinite grades of VR service 216 on a per-PE level. [Example: one PE may be the aggregating point 217 (say headquarters of the corporation) for a given VPN and a number 218 of other PE may be access points (branch offices). In this case, 219 the PE connected to the headquarters may be contracted to provide 220 a large VR while the PE connected to the branch offices may house 221 small, perhaps stub VRs]. This provision also allows the SP to 222 design the network with an end goal of distributing the load among 223 the routers in the network. 225 5.4. As per the traffic requirement we can incrementally add the 226 PEs. 228 5.5. One indicator of the VPN size is the number of PE in the SP's 229 network that have connections to CPE routers in that VPN. In this 230 respect, a VPN with many sites that need to be connected is a 231 "large" VPN whereas one with a few sites is a "small" VPN. Also, 232 it is conceivable that a VPN grows or shrinks in size over time. 233 VPNs may even merge due to corporate mergers, acquisitions and 234 partnering agreements. These changes are easy to accommodate in 235 this architecture, as globally unique IP resources do not have to 236 be dedicated or assigned to VPNs. The number of PE is not limited 237 by any artificial configuration limits. 239 5.6. The SP owns and manages Layer 1 and Layer 2 entities. To be 240 specific, the SP controls physical switches or routers, physical 241 links, logical layer 2 connections (such as DLCI in Frame Relay 242 and VPI/VCI in ATM) and LSPs (and their assignment to specific 243 VPNs). In the context of VPNs, it is the SP's responsibility to 244 contract and assign layer 2 entities to specific VPNs. 246 5.7. Layer 3 entities belong to and are manageable by the PNA. 247 Examples of these entities include IP interfaces, choice of 248 dynamic routing protocols or static routes, and routing 249 interfaces. Note that although Layer 3 configuration logically 250 falls under the PNA's area of responsibility, it is not necessary 251 for the PNA to execute it. It is quite viable for the PNA to 252 outsource the IP administration of the virtual routers to the 253 Service Provider. Regardless of who assumes responsibility for 254 configuration and monitoring, this approach provides a full 255 routing domain view to the PNA and empowers the PNA to design the 256 network to achieve intranet, extranet and traffic engineering 257 goals. 259 5.8. The VPNs can be managed as if physical routers rather than 260 VRs were deployed. Therefore, management may be performed using 261 SNMP or other similar methods or directly at the VR console (VRC). 263 5.9. Industry-standard troubleshooting tools such as 'ping,' 264 'traceroute,' etc., are available in a routing domain exclusively 265 of dedicated physical routers. Therefore, monitoring and 266 troubleshooting may be performed using SNMP or similar methods, 267 but may also include the use of these standard tools. Again, the 268 VRC may be used for these purposes just like any physical router. 270 5.10. Since the VRC is visible to the user, router specific 271 security checks need to be put in place to make sure the VPN user 272 is allowed access to Layer 3 resources in that VPN only and is 273 disallowed from accessing physical resources in the router. Most 274 routers achieve this through the use of database views. 276 5.11. The VRC is available to the SP as well. If configuration and 277 monitoring has been outsourced to the SP, the SP may use the VRC 278 to accomplish these tasks as if it were the PNA. 280 5.12. The VRs in the PE form the VPN in the SP's network. 281 Together, they represent a virtual routing domain. They 282 dynamically discover each other by utilizing variety of technics. 284 5.13. If SPs network supports multicast then routing protocols 285 which uses multicast like OSPF, RIPV2 can be easily supported in 286 VPN. 288 5.14. User data forwarding may be done in one of several ways: 290 5.14.1. An LSP with best-effort characteristics that all VPNS can 291 use. 293 5.14.2. An LSP dedicated to a VPN and traffic engineered by the 294 VPN customer. 296 5.14.3. A private LSP with differentiated characteristics. 298 5.14.4. Policy based forwarding on a dedicated L2 Virtual Circuit 300 The choice of the preferred method is negotiable between the SP and 301 the VPN customer, perhaps constituting part of the SLA between them. 302 This allows the SP to offer different grades of service to different 303 VPN customers. 305 Of course, hop-by-hop forwarding is also available to forward routing 306 packets and to forward user data packets during periods of LSP 307 establishment and failure. 309 5.15. This approach does not mandate that separate operating system 310 tasks for each of the routing protocols be run for each VR that the 311 PE houses. Specific implementations may be tailored to the particular 312 PE in use. Maintaining separate routing databases and forwarding 313 tables, one per VR, is one way to get the highest performance for a 314 given PE. 316 6.0. Scaleable Configuration 318 A typical VPN is expected to have 100s to 1000s of endpoints within 319 the SP cloud. Therefore, configuration should scale (at most) 320 linearly with the number of end points. To be specific, the 321 administrator should have to add a couple of configuration items when 322 a new customer site joins the set of VRs constituting a specific VPN. 323 Anything worse will make this task too daunting for the service 324 provider. In this architecture, all that the service provider needs 325 to allocate and configure is the ingress/egress physical link (e.g. 326 Frame Relay DLCI or ATM VPI/VCI) and the virtual connection between 327 the VR and the Service Provider Core. 329 7.0. VPN IP Domain Configuration 330 151.0.0.1 331 ################ 332 # # 333 # ROUTER 'A' # 334 # # 335 ################ 336 # # 337 # # 338 # # 339 # # 340 ############# ############### 341 # # # # 342 # ROUTER 'B'# # ROUTER 'C' # 343 # # # # 344 # # # # 345 ############# ############### 346 152.0.0.2 153.0.0.3 348 Figure 1 'Physical Routing Domain' 350 The physical domain in the SP's network is shown in Figure.1. In this 351 network, physical routers A, B and C are connected together. Each of 352 the routers has a 'public' IP address assigned to it. These addresses 353 uniquely identify each of the routers in the SP's network. 355 172.150.0/18 172.150.128/18 356 ----------------------- ---------------------------| 357 | | | 358 | | 172.150.128.1 359 | ROUTER 'A' (151.0.0.1) | |---------| 360 | ############# | |Parts DB | 361 | ---#-----------# | /---------/ 362 | OSPF | # # OSPF | /----------/ 363 ------------|# VR - A #|-------------- 364 #-------|---#-| 365 #############10.0.0.1/24 366 |----|------------#-#---------------|-----| 367 |10.0.0.2/24# # |10.0.0.3/24 368 |------|-------| # # ---------|-------| 369 | ############### # |############### | 370 | # VR - B |# # # VR - C # | 371 |#-------------# ROUTER 'B'##|------------#---- 372 (152.0.0.2)############### ############### (153.0.0.3) 373 | | 374 | | 375 ------------------------- ROUTER 'C' | 376 172.150.64/18 V 377 Vendors Extranet 379 Figure 2 'Virtual Routing Domain' 381 Each Virtual Router is configurable by the PNA as though it were a 382 private physical router. Of course, the SP limits the resources that 383 this Virtual Router may consume on a PE-by-PE basis. Each VPN has a 384 number of physical connections (to CE routers) and a number of 385 logical connections (to the emulated LAN). The emulated LAN (shown 386 with IP addresses 10.0.0.x/24) provides the VPN Backbone connecting 387 the VRs in Figure 2. Each connection is IP-capable and can be 388 configured to utilize any combination of the standard routing 389 protocols and routing policies to achieve specific corporate network 390 goals. 392 To illustrate, in Figure 2, 3 VRs reside on 3 PE in VPN 1. Router 'A' 393 houses VR-A, router 'B' houses VR-B and router 'C' houses VR-C. VR-C 394 and VR-B have a physical connection to CE equipment, while VR-A has 2 395 physical connections. Each of the VRs has a fully IP-capable logical 396 connection to the emulated LAN. VR-A has the (physical) connections 397 to the headquarters of the company and runs OSPF over those 398 connections. Therefore, it can route packets to 172.150.0/18 and 399 172.150.128/18. VR-B runs RIP in the branch office (over the physical 400 connection) and uses RIP (over the logical connection) to export 401 172.150.64/18 to VR-A. VR-A advertises a default route to VR-B over 402 the logical connection. Vendors use VR-C as the extranet connection 403 to connect to the parts database at 172.150.128.1. Hence, VR-C 404 advertises a default route to VR-A over the logical connection. VR-A 405 exports only 175.150.128.1 to VR-C. This keeps the rest of the 406 corporate network from a security problem. 408 The network administrator will configure the following: 410 7.1. OSPF connections to the 172.150.0/18 and 172.150.128/18 network 411 in VR-A. 413 7.2. RIP connections to VR-B and VR-C on VR-A. 415 7.3. Route policies on VR-A to advertise only the default route to 416 VR-B. 418 7.4. Route policies on VR-A to advertise only 172.150.128.1 to VR-C. 420 7.5. RIP on VR-B to VR-A. 422 7.6. RIP on VR-C to advertise a default route to VR-A. 424 8.0. Forwarding 426 As mentioned in the architectural outline, data forwarding may be 427 done in one of several ways. In all techniques except the Hop-by-Hop 428 technique for forwarding routing/control packets, the actual method 429 is configurable. At the high end, policy based forwarding for quick 430 service and at the other end best effort forwarding using public LSP 431 is used. The order of forwarding preference is as follows: 433 - Policy based forwarding. 435 - Optionally configured private LSP. 437 - Best-effort public LSP. 439 8.1 Private LSP 441 This LSP is optionally configured on a per-VPN basis. This LSP is 442 usually associated with non-zero bandwidth reservation and/or a 443 specific differentiated service or QOS class. If this LSP is 444 available, it is used for user data and for VPN private control data 445 forwarding. 447 8.2 Best Effort Public LSP 449 VPN data packets are forwarded using this LSP if a private LSP with 450 specified bandwidth and/or QOS characteristics is either not 451 configured or not presently available. The LSP used is the one 452 destined for the egress router in VPN 0.(i.e., the reserved VPNID 453 designating the public Internet). The VPNID in the shim header is 454 used to de-multiplex data packets from various VPNs at the egress 455 router. 457 9.0. Differentiated Services 459 Configuring private LSPs for VPNs allows the SP to offer 460 differentiated services to paying customers. These private LSPs could 461 be associated with any available L2 QOS class or Diff-Serv 462 codepoints. In a VPN, multiple private LSPs with different service 463 classes could be configured with flow profiles for sorting the 464 packets among the LSPs. This feature, together with the ability to 465 size the virtual routers, allows the SP to offer truly differentiated 466 services to the VPN customer. 468 10.0. Security Considerations 470 10.1 Routing Security 472 The use of standard routing protocols such as OSPF and BGP in their 473 unmodified form means that all the encryption and security methods 474 (such as MD5 authentication of neighbors) are fully available in VRs. 475 Making sure that routes are not accidentally leaked from one VPN to 476 another is an implementation issue. One way to achieve this is to 477 maintain separate routing and forwarding databases. 479 10.2 Data Security 481 This allows the SP to assure the VPN customer that data packets in 482 one VPN never have the opportunity to wander into another. From a 483 routing standpoint, this could be achieved by maintaining separate 484 routing databases for each virtual router. From a data forwarding 485 standpoint, the use of label stacks in the case of shared LSPs 486 [Rosen2] [Callon] or the use of private LSPs guarantees data privacy. 487 Packet filters may also be configured to help ease the problem. 489 10.3 Configuration Security 491 Virtual routers appear as physical routers to the PNA. This means 492 that they may be configured by the PNA to achieve connectivity 493 between offices of a corporation. Obviously, the SP has to guarantee 494 that the PNA and the PNA's designees are the only ones who have 495 access to the VRs on the PE the private network has connections to. 496 Since the virtual router console is functionally equivalent to a 497 physical router, all of the authentication methods available on a 498 physical console such as password, RADIUS, etc. are available to the 499 PNA. 501 10.4 Physical Network Security 503 When a PNA logs in to a PE to configure or monitor the VPN, the PNA 504 is logged into the VR for the VPN. The PNA has only layer 3 505 configuration and monitoring privileges for the VR. Specifically, the 506 PNA has no configuration privileges for the physical network. This 507 provides the guarantee to the SP that a VPN administrator will not be 508 able to inadvertently or otherwise adversely affect the SP's network. 510 11.0. Virtual Router Monitoring 512 All of the router monitoring features available on a physical router 513 are available on the virtual router. This includes utilities such as 514 "ping" and "traceroute". In addition, the ability to display private 515 routing tables, link state databases, etc. are available. 517 12.0. Performance Considerations 519 For the purposes of discussing performance and scaling issues, 520 today's routers can be split into two planes: the routing (control) 521 plane and the forwarding plane. 523 In looking at the routing plane, most modern-day routing protocols 524 use some form of optimized calculation methodologies to calculate the 525 shortest path(s) to end stations. For instance, OSPF and ISIS use the 526 Djikstra algorithm while BGP uses the "Decision Process". These 527 algorithms are based on parsing the routing database and computing 528 the best paths to end stations. The performance characteristics of 529 any of these algorithms is based on either topological 530 characteristics (ISIS and OSPF) or the number of ASs in the path to 531 the destinations (BGP). But it is important to note that the overhead 532 in setting up and beginning these calculations is very little for 533 most any modern day router. This is because, although we refer to 534 routing calculation input as "databases", these are memory resident 535 data structures. 537 Therefore, the following conclusions can be drawn: 539 1. Beginning a routing calculation for a routing domain is nothing 540 more than setting up some registers to point to the right database 541 objects. 543 2. Based on 1, the performance of a given algorithm is not 544 significantly worsened by the overhead required to set it up. 546 3. Based on 2, it follows that, when a number of routing calculations 547 for a number of virtual routers has to be performed by a physical 548 router, the complexity of the resulting routing calculation is 549 nothing more than the sum of the complexities of the routing 550 calculations of the individual virtual routers. 552 4. Based on 3, it follows that whether an overlay model is used or a 553 virtual routing model is employed, the performance characteristics of 554 a router are dependent purely on its hardware capabilities and the 555 choice of data structures and algorithms. 557 To illustrate, let's say a physical router houses N VPNs, all running 558 some routing protocol say RP. Let's also suppose that the average 559 performance of RP's routing calculation algorithm is f(X,Y) where x 560 and y are parameters that determine performance of the algorithm for 561 that routing protocol. As an example, for Djikstra algorithm users 562 such as OSPF, X could be the number of nodes in the area while Y 563 could be the number of links. The performance of an arbitrary VPN n 564 is f (Xn, Yn). The performance of the (physical) router is the sum of 565 f(Xi, Yi) for all values of i in 0 <= i <= N. This conclusion is 566 independent of the chosen VPN approach (virtual router or overlay 567 model). 569 In the usual case, the forwarding plane has two inputs: the 570 forwarding table and the packet header. The main performance 571 parameter is the lookup algorithm. The very best performance one can 572 get for a IP routing table lookup is by organizing the table as some 573 form of a tree and use binary search methods to do the actual lookup. 574 The performance of this algorithm is O(log n). 576 Hence, as long as the virtual routers' routing tables are distinct 577 from each other, the lookup cost is constant for finding the routing 578 table and O(log n) to find the entry. This is no worse or different 579 from any router and no different from a router that employs overlay 580 techniques to deliver VPN services. However, when the overlay router 581 utilizes integration of multiple VPNs' routing tables, the 582 performance is O(log m*n) where 'm' is the number of VPNs that the 583 routing table holds routes for. 585 13.0. Some Applications 587 Some typical applications of PPVPN are illustrated here to assist 588 better understanding of the PPVPNs. 590 13.1. Example 1 591 World HQ wants to connect Regional HQs and small stationary 592 outlet/storage. 594 ( ) +-+ 595 ( ) ( )-----| | 596 ( ) ( ) +-+ Regional Office 1 597 ( C(HQ))-----( SP ) 598 ( ) ( ) +-+ 599 ( ) ( )------| | Regional office 2 600 ( ) +-+ 602 13.2. Example 2: 604 In the similar model as said above the SP's network may differ. More 605 than one SP will be involved in connecting the corporate user. In 606 that case we need a SLA between SPs for the service. 608 ( ) ( ) +-+ 609 ( ) ( )-----(SP2)---| | 610 ( ) ( ) ( ) +-+ Regional Office 1 611 ( C(HQ))-----( SP1 ) 612 ( ) ( ) +-+ 613 ( ) ( )------| | Regional office 2 614 ( ) +-+ 616 We need a policy between two SP's VPN for exchange of routes. We 617 need VPN id conversion since the VPNs may have different ID in each 618 SP. 620 13.3. Example 3: When a Mobile user wants to join the VPN, the 621 connection can be made by an LSP tunnel or an IPSec tunnel to the 622 nearest VPN PE. 624 ( ) ( ) +-+ 625 ( ) ( )-----(SP2)---| | 626 ( ) ( ) ( ) +-+ Regional Office 1 +-+ 627 ( C(HQ))-----( SP1 )----------//-----------------------| | 628 ( ) ( ) +-+ +-+ 629 ( ) ( )------| | Regional office 2 Mobile user 630 ( ) +-+ 632 13.4. Hierarchical VPNs 634 +-+ 635 +---| | Blue VPN 636 +-+ Blue VPN | +-+ 637 | | ( ) Y ( ) +-+ 638 +-+-- ( ) ( )-----(SP2)---| | 639 ( ) Y ( ) (G) +-+ Red VPN 640 ( SP2B )-----( SP1 ) 641 ( ) ( ) Y ( ) +-+ 642 ( ) ( )------(SP2)---| | Red VPN 643 +-+ | ( ) (F) +-+ 644 | |-------+ | +-+ 645 +-+ Red VPN +--------------| | Blue VPN 646 +-+ 648 Y - Yellow VPN. Which SP2 gets from SP1. 650 SP2 bought Yellow VPN from SP1. SP2 has branch offices as SP2B, SP2G 651 and SP2F in different locations. SP2 also provides VPN services and 652 Red and Blue VPNs are SP2's customers. 654 SP2B CE for VPN Y towards SP1 will have the instance of Blue Red and 655 Yellow VPNs. Relation between Yellow VPN and Blue/Red VPN is 656 configured by policy. Yellow VPN provides separate transport for 657 Red/Blue VPNs, it does not participate in routing, which keeps all 658 the VPNs separate to each other, but still they can use the upper 659 level VPN for transport. In this example Client of SP2B Red VPN can 660 peer with RedVPN in SP2G. SP2G will peer with SP2B in Yellow VPN. 661 Data from RedVPN in SP2B will use Yellow VPN link from SP2B through 662 SP1 to SP2G. Data from BlueVPN will also use the same path or same 663 LSP. In SP2G it will be demuxed to reach Red/Blue VPNs. Here 664 YellowVPN acts like a LSP tunnel to Red/Blue VPNs. 666 14.0. References 668 [Callon] Callon R., et al, "A framework for Multiprotocol Label 669 Switching", draft-ietf-mpls-framework-05.txt. 671 [Fox] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685. 673 [Meyer] Meyer D., "Administratively Scoped IP Multicast", RFC 2365. 675 [Rosen1] Rosen, E., et al. draft-rosen-rfc2547bis-02.txt 677 [Rosen2] Rosen E., et al, "Multiprotocol Label Switching 678 Architecture", draft-ietf-mpls-arch-06.txt. 680 [muthuk] K.Muthukrishnan, A.Malis "A Core MPLS IP VPN Architecture", 681 RFC 2917 September 2000. 683 [VPN-FRAME] M.Suzuki, J.Sumimoto, "A Framework for Network-based 684 VPNs", , October 2000. 686 15. Authors' addresses 688 Karthik Muthukrishnan 689 Lucent Technologies 690 1 Robbins Road 691 Phone: (978) 952-1368 692 Westford, MA 01886 693 Email: mkarthik@lucent.com 695 Andrew Malis 696 Vivace Networks, Inc. 697 2730 Orchard Parkway 698 San Jose, CA 95134 699 Phone: (408) 383-7223 700 EMail: Andy.Malis@vivacenetworks.com 702 Chandrasekar Kathirvelu 703 Lucent Technologies 704 1 Robbins Road 705 Westford, MA 01886 706 Phone: (978) 952-7116 707 EMail: ck32@lucent.com 709 Tom Walsh 710 Lucent Technologies 711 10 Lyberty Way 712 Westford, MA 01886 713 Phone: (978) 392-2311 714 EMail: tdwalsh@lucent.com 715 Fred Ammann 716 COMMCARE Telecommunications 717 Turmstrasse 8 718 CH-8952 Schlieren 719 Switzerland 720 Phone: +41 1 738 61 11 721 Email: fa@commcare.ch 723 Jing Ming Xiao 724 China UNICOM 725 Data & Fixed Communication Department 726 6/F Office Tower 3 727 Henderson Center 728 Beijing, China 729 Email: unicomnet@bj.cnuninet.net 731 Junichi Sumimoto 732 NTT Information Sharing Platform Labs 733 3-9-11, Midori-cho 734 Musashino-shi, Tokyo 180-8585 735 Japan 736 Email: sumimoto.junichi@lab.ntt.co.jp