idnits 2.17.1 draft-muthukrishnan-mpls-corevpn-arch-03.txt: ** The Abstract section seems to be numbered 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? == 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 Introduction 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 71 has weird spacing: '... use of an em...' == Line 594 has weird spacing: '...ithm is f(X,Y...' -- 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 (June 22, 2000) is 8708 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) -- Possible downref: Normative reference to a draft: ref. 'Callon' ** Obsolete normative reference: RFC 2547 (ref. 'Rosen1') (Obsoleted by RFC 4364) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-06 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Karthik Muthukrishnan 2 INTERNET-DRAFT Andrew Malis 3 Expires December 22, 2000 Lucent Technologies 4 June 22, 2000 6 A Core MPLS IP VPN Architecture 8 1. Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 This draft is not a product of any working group and was written and 24 presented to the IETF well before the formation of any working group 25 related to Core VPNs. 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Acronyms 35 ARP Address Resolution Protocol 36 CE Customer Edge router 37 LSP Label Switched Path 38 PNA Private Network Administrator 39 SLA Service Level Agreement 40 SP Service Provider 41 SPED Service Provider Edge Device 42 SPNA SP Network Administrator 43 VMA VPN Multicast Address 44 VPNID VPN Identifier 45 VR Virtual Router 46 VRC Virtual Router Console 48 3. Abstract 50 This draft presents an approach for building core VPN services in a 51 service provider's MPLS backbone. This approach uses MPLS running in 52 the backbone to provide premium services in addition to best effort 53 services. The central vision is for the service provider to provide a 54 virtual router service to their customers. The keystones of this 55 architecture are ease of configuration, user security, network 56 security, dynamic neighbor discovery, scaling and the use of existing 57 routing protocols as they exist today without any modifications. 59 4. Introduction 61 This draft describes an approach for building IP VPN services out of 62 the backbone of the SP's network. Broadly speaking, two possible 63 approaches present themselves: the overlay model and the virtual 64 router approach. The overlay model is based on overloading some 65 semantic(s) of existing routing protocols to carry reachability 66 information. In this document, we focus on the virtual router 67 service. 69 The approach presented here does not depend on any modifications of 70 any existing routing protocols. Neighbor discovery is aided by the 71 use of an emulated LAN and is achieved by the use of ARP. This draft 72 makes a concerted effort to draw the line between the SP and the PNA: 73 the SP owns and manages layer 1 and layer 2 services while layer 3 74 services belong to and are manageable by the PNA. By the provisioning 75 of fully logically independent routing domains, the PNA has been 76 given the flexibility to use private and unregistered addresses. Due 77 to the use of private LSPs and the use of VPNID encapsulation using 78 label stacks over shared LSPs, data security is not an issue. 80 The approach espoused in this draft differs from that described in 81 RFC 2547 [Rosen1] in that no specific routing protocol has been 82 overloaded to carry VPN routes. RFC 2547 specifies a way to modify 83 BGP to carry VPN unicast routes across the SP's backbone. To carry 84 multicast routes, further architectural work will be necessary. 86 5. Virtual Routers 88 A virtual router is a collection of threads, either static or 89 dynamic, in a routing device, that provides routing and forwarding 90 services much like physical routers. A virtual router need not be a 91 separate operating system process (although it could be); it simply 92 has to provide the illusion that a dedicated router is available to 93 satisfy the needs of the network(s) to which it is connected. A 94 virtual router, like its physical counterpart, is an element in a 95 routing domain. The other routers in this domain could be physical or 96 virtual routers themselves. Given that the virtual router connects to 97 a specific (logically discrete) routing domain and that a physical 98 router can support multiple virtual routers, it follows that a 99 physical router supports multiple (logically discreet) routing 100 domains. 102 From the user (VPN customer) standpoint, it is imperative that the 103 virtual router be as equivalent to a physical router as possible. In 104 other words, with very minor and very few exceptions, the virtual 105 router should appear for all purposes (configuration, management, 106 monitoring and troubleshooting) like a dedicated physical router. The 107 main motivation behind this requirement is to avoid upgrading or re- 108 configuring the large installed base of routers and to avoid 109 retraining of network administrators. 111 The aspects of a router that a virtual router needs to emulate are: 113 1. Configuration of any combination of routing protocols 115 2. Monitoring of the network 117 3. Troubleshooting. 119 Every VPN has a logically independent routing domain. This enhances 120 the SP's ability to offer a fully flexible virtual router service 121 that can fully serve the SP's customer without requiring physical 122 per-VPN routers. This means that the SP's "hardware" investments, 123 namely routers and links between them, can be re-used by multiple 124 customers. 126 6. Objectives 128 1. Easy, scalable configuration of VPN endpoints in the service 129 provider network. At most, one piece of configuration should be 130 necessary when a CE is added. 132 2. No use of SP resources that are globally unique and hard to get 133 such as IP addresses and subnets. 135 3. Dynamic discovery of VRs (Virtual Routers) in the SP's cloud. This 136 is an optional, but extremely valuable "keep it simple" goal. 138 4. Virtual Routers should be fully configurable and monitorable by 139 the VPN network administrator. This provides the PNA with the 140 flexibility to either configure the VPN themselves or outsource 141 configuration tasks to the SP. 143 5. Quality of data forwarding should be configurable on a VPN-by-VPN 144 basis. This should translate to continuous (but perhaps discrete) 145 grades of service. Some examples include best effort, dedicated 146 bandwidth, QOS, and policy based forwarding services. 148 6. Differentiated services should be configurable on a VPN-by-VPN 149 basis, perhaps based on LSPs set up for exclusive use for forwarding 150 data traffic in the VPN. 152 7. Security of internet routers extended to virtual routers. This 153 means that the virtual router's data forwarding and routing functions 154 should be as secure as a dedicated, private physical router. There 155 should be no unintended leak of information (user data and 156 reachability information) from one routing domain to another. 158 8. Specific routing protocols should not be mandated between virtual 159 routers. This is critical to ensuring the VPN customer can setup the 160 network and policies as the customer sees fit. For example, some 161 protocols are strong in filtering, while others are strong in traffic 162 engineering. The VPN customer might want to exploit both to achieve 163 "best of breed" network quality. 165 9. No special extensions to existing routing protocols such as BGP, 166 RIP, OSPF, ISIS etc. This is critical to allowing the future addition 167 of other services such as NHRP and multicast. In addition, as 168 advances and addenda are made to existing protocols (such as traffic 169 engineering extensions to ISIS and OSPF), they can be easily 170 incorporated into the VPN implementation. 172 7. Architectural Requirements 174 The service provider network must run some form of multicast routing 175 to all nodes that will have VPN connections and to nodes that must 176 forward multicast datagrams for virtual router discovery. A specific 177 multicast routing protocol is not mandated. An SP may run MOSPF or 178 DVMRP or any other protocol. 180 8. Architectural Outline 182 1. Every VPN is assigned a VPNID which is unique within the SP's 183 network. This identifier unambiguously identifies the VPN with which 184 a packet or connection is associated. The VPNID of zero is reserved; 185 it is associated with and represents the public internet. It is 186 recommended, but not required that these VPN identifiers will be 187 compliant with RFC 2685 [Fox]. 189 2. The VPN service is offered in the form of a Virtual Router 190 service. These VRs reside in the SPED and are as such confined to 191 the edge of the SP's cloud. The VRs will use the SP's network for 192 data and control packet forwarding but are otherwise invisible 193 outside the SPEDs. 195 3. The "size" of the VR contracted to the VPN in a given SPED is 196 expressed by the quantity of IP resources such as routing interfaces, 197 route filters, routing entries etc. This is entirely under the 198 control of the SP and provides the fine granularity that the SP 199 requires to offer virtually infinite grades of VR service on a per- 200 SPED level. [Example: one SPED may be the aggregating point (say 201 headquarters of the corporation) for a given VPN and a number of 202 other SPEDs may be access points (branch offices). In this case, the 203 SPED connected to the headquarters may be contracted to provide a 204 large VR while the SPEDs connected to the branch offices may house 205 small, perhaps stub VRs]. This provision also allows the SP to design 206 the network with an end goal of distributing the load among the 207 routers in the network. 209 4. One indicator of the VPN size is the number of SPEDs in the SP's 210 network that have connections to CPE routers in that VPN. In this 211 respect, a VPN with many sites that need to be connected is a "large" 212 VPN whereas one with a few sites is a "small" VPN. Also, it is 213 conceivable that a VPN grows or shrinks in size over time. VPNs may 214 even merge due to corporate mergers, acquisitions and partnering 215 agreements. These changes are easy to accommodate in this 216 architecture, as globally unique IP resources do not have to be 217 dedicated or assigned to VPNs. The number of SPEDs is not limited by 218 any artificial configuration limits. 220 5. The SP owns and manages Layer 1 and Layer 2 entities. To be 221 specific, the SP controls physical switches or routers, physical 222 links, logical layer 2 connections (such as DLCI in Frame Relay and 223 VPI/VCI in ATM) and LSPs (and their assignment to specific VPNs). In 224 the context of VPNs, it is the SP's responsibility to contract and 225 assign layer 2 entities to specific VPNs. 227 6. Layer 3 entities belong to and are manageable by the PNA. Examples 228 of these entities include IP interfaces, choice of dynamic routing 229 protocols or static routes, and routing interfaces. Note that 230 although Layer 3 configuration logically falls under the PNA's area 231 of responsibility, it is not necessary for the PNA to execute it. It 232 is quite viable for the PNA to outsource the IP administration of the 233 virtual routers to the Service Provider. Regardless of who assumes 234 responsibility for configuration and monitoring, this approach 235 provides a full routing domain view to the PNA and empowers the PNA 236 to design the network to achieve intranet, extranet and traffic 237 engineering goals. 239 7. The VPNs can be managed as if physical routers rather than VRs 240 were deployed. Therefore, management may be performed using SNMP or 241 other similar methods or directly at the VR console (VRC). 243 8. Industry-standard troubleshooting tools such as 'ping,' 244 'traceroute,' in a routing domain domain comprised exclusively of 245 dedicated physical routers. Therefore, monitoring and 246 troubleshooting may be performed using SNMP or similar methods, but 247 may also include the use of these standard tools. Again, the VRC may 248 be used for these purposes just like any physical router. 250 9. Since the VRC is visible to the user, router specific security 251 checks need to be put in place to make sure the VPN user is allowed 252 access to Layer 3 resources in that VPN only and is disallowed from 253 accessing physical resources in the router. Most routers achieve 254 this through the use of database views. 256 10. The VRC is available to the SP as well. If configuration and 257 monitoring has been outsourced to the SP, the SP may use the VRC to 258 accomplish these tasks as if it were the PNA. 260 11. The VRs in the SPEDs form the VPN in the SP's network. Together, 261 they represent a virtual routing domain. They dynamically discover 262 each other by utilizing an emulated LAN resident in the SP's network. 264 Each VPN in the SP's network is assigned one and only one multicast 265 address. This address is chosen from the administratively scoped 266 range (239.192/14) [Meyer] and the only requirement is that the 267 multicast address can be uniquely mapped to a specific VPN. This is 268 easily automated by routers by the use of a simple function to 269 unambiguously map a VPNid to the multicast address. Subscription to 270 this multicast address allows a VR to discover and be discovered by 271 other VRs. It is important to note that the multicast address does 272 not have to be configured. 274 12. Data forwarding may be done in one of several ways: 276 1. An LSP with best-effort characteristics that all VPNS can use. 278 2. An LSP dedicated to a VPN and traffic engineered by the VPN 279 customer. 281 3. A private LSP with differentiated characteristics. 283 4. Policy based forwarding on a dedicated L2 Virtual Circuit 285 The choice of the preferred method is negotiable between the SP and 286 the VPN customer, perhaps constituting part of the SLA between them. 287 This allows the SP to offer different grades of service to different 288 VPN customers. 290 Of course, hop-by-hop forwarding is also available to forward routing 291 packets and to forward user data packets during periods of LSP 292 establishment and failure. 294 13. This approach does not mandate that separate operating system 295 tasks for each of the routing protocols be run for each VR that the 296 SPED houses. Specific implementations may be tailored to the 297 particular SPED in use. Maintaining separate routing databases and 298 forwarding tables, one per VR, is one way to get the highest 299 performance for a given SPED. 301 9. Scalable Configuration 303 A typical VPN is expected to have 100s to 1000s of endpoints within 304 the SP cloud. Therefore, configuration should scale (at most) 305 linearly with the number of end points. To be specific, the 306 administrator should have to add a couple of configuration items when 307 a new customer site joins the set of VRs constituting a specific VPN. 308 Anything worse will make this task too daunting for the service 309 provider. In this architecture, all that the service provider needs 310 to allocate and configure is the ingress/egress physical link (e.g. 311 Frame Relay DLCI or ATM VPI/VCI) and the virtual connection between 312 the VR and the emulated LAN. 314 10. Dynamic Neighbor Discovery 316 The VRs in a given VPN reside in a number of SPEDs in the network. 317 These VRs need to learn about each other and be connected. 319 One way to do this is to require the manual configuration of 320 neighbors. As an example, when a new site is added to a VPN, this 321 would require the configuration of all the other VRs as neighbors. 322 This is obviously not scalable from a configuration and network 323 resource standpoint. 325 The need then arises to allow these VRs to dynamically discover each 326 other. Neighbor discovery is facilitated by providing each VPN with 327 a limited emulated LAN. This emulated LAN is used in several ways: 329 1. Address resolution uses this LAN to resolve next-hop (private) IP 330 addresses associated with the other VRs. 332 2. Routing protocols such as RIP and OSPF use this limited emulated 333 LAN for neighbor discovery and to send routing updates. 335 The per-VPN LAN is emulated using an IP multicast address. In the 336 interest of conserving public address space and because this 337 multicast address needs to be visible only in the SP network space, 338 we would use an address from the Organizationally scoped multicast 339 addresses (239.192/14) as described in [Meyer]. Each VPN is allocated 340 an address from this range. To completely eliminate configuration in 341 this regard, this address is computed from the VPNID. 343 10. VPN IP Domain Configuration 345 151.0.0.1 346 ################ 347 # # 348 # ROUTER 'A' # 349 # # 350 ################ 351 # # 352 # # 353 # # 354 # # 355 ############# ############### 356 # # # # 357 # ROUTER 'B'# # ROUTER 'C' # 358 # # # # 359 # # # # 360 ############# ############### 361 152.0.0.2 153.0.0.3 363 Figure 1 'Physical Routing Domain' 365 The physical domain in the SP's network is shown in the above figure. 366 In this network, physical routers A, B and C are connected together. 367 Each of the routers has a 'public' IP address assigned to it. These 368 addresses uniquely identify each of the routers in the SP's network. 370 172.150.0/18 172.150.128/18 371 ----------------------- ---------------------------| 372 | | | 373 | | 172.150.128.1 374 | ROUTER 'A' (151.0.0.1) | |---------| 375 | ############# | |Parts DB | 376 | ---#-----------# | /---------/ 377 | OSPF | # # ISIS | /----------/ 378 ------------|# VR - A #|-------------- 379 #-------|---#-| 380 #############10.0.1/24 381 |----|------------#-#---------------|-----| 382 |10.0.0.2/24# # |10.0.0.3/24 383 |------|-------| # # ---------|-------| 384 | ############### # |############### | 385 | # VR - B |# # # VR - C # | 386 |#-------------# ROUTER 'B'##|------------#---- 387 (152.0.0.2)############### ############### (153.0.0.3) 388 ------------------------- ROUTER 'C' | Extranet 389 172.150.64/18 V 390 Vendors 392 Figure 2 'Virtual Routing Domain' 394 Each Virtual Router is configurable by the PNA as though it were a 395 private physical router. Of course, the SP limits the resources that 396 this Virtual Router may consume on a SPED-by-SPED basis. Each VPN has 397 a number of physical connections (to CPE routers) and a number of 398 logical connections (to the emulated LAN). Each connection is IP- 399 capable and can be configured to utilize any combination of the 400 standard routing protocols and routing policies to achieve specific 401 corporate network goals. 403 To illustrate, in Figure 1, 3 VRs reside on 3 SPEDs in VPN 1. Router 404 'A' houses VR-A, router 'B' houses VR-B and router 'C' houses VR-C. 405 VR-C and VR-B have a physical connection to CPE equipment, while VR-A 406 has 2 physical connections. Each of the VRs has a fully IP-capable 407 logical connection to the emulated LAN. VR-A has the (physical) 408 connections to the headquarters of the company and runs OSPF over 409 those connections. Therefore, it can route packets to 172.150.0/18 410 and 172.150.128/18. VR-B runs RIP in the branch office (over the 411 physical connection) and uses RIP (over the logical connection) to 412 export 172.150.64/18 to VR-A. VR-A advertises a default route to VR-B 413 over the logical connection. Vendors use VR-C as the extranet 414 connection to connect to the parts database at 172.150.128.1. Hence, 415 VR-C advertises a default route to VR-A over the logical connection. 416 VR-A exports only 175.150.128.1 to VR-C. This keeps the rest of the 417 corporate network from a security problem. 419 The network administrator will configure the following: 421 1. OSPF connections to the 172.150.0/18 and 172.150.128/18 network 422 in VR-A. 424 2. RIP connections to VR-B and VR-C on VR-A. 426 3. Route policies on VR-A to advertise only the default route to VR- 427 B. 429 4. Route policies on VR-A to advertise only 172.159.128.1 to VR-C. 431 5. RIP on VR-B to VR-A. 433 6. RIP on VR-C to advertise a default route to VR-A. 435 11. Neighbor Discovery Example 437 In Figure #1, the SPED that houses VR-A (SPED-A) uses a public 438 address of 150.0.0.1/24, SPED-B uses 150.0.0.2/24 and SPED-C uses 439 150.0.0.3/24. As noted, the connection between the VRs is via an 440 emulated LAN. For interface addresses on the emulated LAN 441 connection, VR-A uses 10.0.0.1/24, VR-B uses 10.0.0.2/24 and VR-C 442 uses 10.0.0.3/24. 444 Let's take the case of VR-A sending a packet to VR-B. To get VR-B's 445 address (SPED-B's address), VR-A sends an ARP request packet with the 446 address of VR-B (10.0.0.2) as the logical address. The source logical 447 address is 10.0.0.1 and the hardware address is 151.0.0.1. This ARP 448 request is encapsulated in this VPN's multicast address and sent out. 449 SPED B and SPED-C receive a copy of the packet. SPED-B recognizes 450 10.0.0.2 in the context of VPN 1 and responds with 152.0.0.2 as the 451 "hardware" address. This response is sent to the VPN multicast 452 address to promote the use of promiscuous ARP and the resulting 453 decrease in network traffic. 455 Manual configuration would be necessary if neighbor discovery were 456 not used. In this example, VR-A would be configured with a static ARP 457 entry for VR-B's logical address (10.0.0.1) with the "hardware" 458 address set to 152.0.0.2. 460 12. Forwarding 462 As mentioned in the architectural outline, data forwarding may be 463 done in one of several ways. In all techniques except the Hop-by-Hop 464 technique for forwarding routing/control packets, the actual method 465 is configurable. At the high end, policy based forwarding for quick 466 service and at the other end best effort forwarding using public LSP 467 is used. The order of forwarding preference is as follows: 469 1. Policy based forwarding. 471 2. Optionally configured private LSP. 473 3. Best-effort public LSP. 475 12.1 Private LSP 477 This LSP is optionally configured on a per-VPN basis. This LSP is 478 usually associated with non-zero bandwidth reservation and/or a 479 specific differentiated service or QOS class. If this LSP is 480 available, it is used for user data and for VPN private control data 481 forwarding. 483 12.2 Best Effort Public LSP 485 VPN data packets are forwarded using this LSP if a private LSP with 486 specified bandwidth and/or QOS characteristics is either not 487 configured or not presently available. The LSP used is the one 488 destined for the egress router in VPN 0. The VPNID in the shim header 489 is used to de-multiplex data packets from various VPNs at the egress 490 router. 492 13. Differentiated Services 494 Configuring private LSPs for VPNs allows the SP to offer 495 differentiated services to paying customers. These private LSPs could 496 be associated with any available L2 QOS class or Diff-Serv 497 codepoints. In a VPN, multiple private LSPs with different service 498 classes could be configured with flow profiles for sorting the 499 packets among the LSPs. This feature, together with the ability to 500 size the virtual routers, allows the SP to offer truly differentiated 501 services to the VPN customer. 503 14. Security Considerations 505 14.1 Routing Security 507 The use of standard routing protocols such as OSPF and BGP in their 508 unmodified form means that all the encryption and security methods 509 (such as MD5 authentication of neighbors) are fully available in VRs. 510 Making sure that routes are not accidentally leaked from one VPN to 511 another is an implementation issue. One way to achieve this is to 512 maintain separate routing and forwarding databases. 514 14.2 Data Security 516 This allows the SP to assure the VPN customer that data packets in 517 one VPN never have the opportunity to wander into another. From a 518 routing standpoint, this could be achieved by maintaining separate 519 routing databases for each virtual router. From a data forwarding 520 standpoint, the use of label stacks in the case of shared LSPs 521 [Rosen2] [Callon] or the use of private LSPs guarantees data privacy. 522 Packet filters may also be configured to help ease the problem. 524 14.3 Configuration Security 526 Virtual routers appear as physical routers to the PNA. This means 527 that they may be configured by the PNA to achieve connectivity 528 between offices of a corporation. Obviously, the SP has to guarantee 529 that the PNA and the PNA's designees are the only ones who have 530 access to the VRs on the SPEDs the private network has connections 531 to. Since the virtual router console is functionally equivalent to a 532 physical router, all of the authentication methods available on a 533 physical console such as password, RADIUS, etc. are available to the 534 PNA. 536 14.4 Physical Network Security 538 When a PNA logs in to a SPED to configure or monitor the VPN, the PNA 539 is logged into the VR for the VPN. The PNA has only layer 3 540 configuration and monitoring privileges for the VR. Specifically, the 541 PNA has no configuration privileges for the physical network. This 542 provides the guarantee to the SP that a VPN administrator will not be 543 able to inadvertently or otherwise adversely affect the SP's network. 545 15. Virtual Router Monitoring 547 All of the router monitoring features available on a physical router 548 are available on the virtual router. This includes utilities such as 549 "ping" and "traceroute". In addition, the ability to display private 550 routing tables, link state databases, etc. are available. 552 16. Performance Considerations 554 For the purposes of discussing performance and scaling issues, 555 today's routers can be split into two planes: the routing (control) 556 plane and the forwarding plane. 558 In looking at the routing plane, most modern-day routing protocols 559 use some form of optimized calculation methodologies to calculate the 560 shortest path(s) to end stations. For instance, OSPF and ISIS use the 561 Djikstra algorithm while BGP uses the "Decision Process". These 562 algorithms are based on parsing the routing database and computing 563 the best paths to end stations. The performance characteristics of 564 any of these algorithms is based on either topological 565 characteristics (ISIS and OSPF) or the number of ASs in the path to 566 the destinations (BGP). But it is important to note that the overhead 567 in setting up and beginning these calculations is very little for 568 most any modern day router. This is because, although we refer to 569 routing calculation input as "databases", these are memory resident 570 data structures. 572 Therefore, the following conclusions can be drawn: 574 1. Beginning a routing calculation for a routing domain is nothing 575 more than setting up some registers to point to the right database 576 objects. 578 2. Based on 1, the performance of a given algorithm is not 579 significantly worsened by the overhead required to set it up. 581 3. Based on 2, it follows that, when a number of routing calculations 582 for a number of virtual routers has to be performed by a physical 583 router, the complexity of the resulting routing calculation is 584 nothing more than the sum of the complexities of the routing 585 calculations of the individual virtual routers. 587 4. Based on 3, it follows that whether an overlay model is used or a 588 virtual routing model is employed, the performance characteristics of 589 a router are dependent purely on its hardware capabilities and the 590 choice of data structures and algorithms. 592 To illustrate, let's say a physical router houses N VPNs, all running 593 some routing protocol say RP. Let's also suppose that the average 594 performance of RP's routing calculation algorithm is f(X,Y) where x 595 and y are parameters that determine performance of the algorithm for 596 that routing protocol. As an example, for Djikstra algorithm users 597 such as OSPF, X could be the number of nodes in the area while Y 598 could be the number of links. The performance of an arbitrary VPN n 599 is f (Xn, Yn). The performance of the (physical) router is the sum of 600 f(Xi, Yi) for all values of i in 0 <= i <= N. This conclusion is 601 independent of the chosen VPN approach (virtual router or overlay 602 model). 604 In the usual case, the forwarding plane has two inputs: the 605 forwarding table and the packet header. The main performance 606 parameter is the lookup algorithm. The very best performance one can 607 get for a IP routing table lookup is by organizing the table as some 608 form of a tree and use binary search methods to do the actual lookup. 609 The performance of this algorithm is O(log n). 611 Hence, as long as the virtual routers' routing tables are distinct 612 from each other, the lookup cost is constant for finding the routing 613 table and O(log n) to find the entry. This is no worse or different 614 from any router and no different from a router that employs overlay 615 techniques to deliver VPN services. However, when the overlay router 616 utilizes integration of multiple VPNs' routing tables, the 617 performance is O(log m*n) where 'm' is the number of VPNs that the 618 routing table holds routes for. 620 17. Acknowledgements 622 The authors wish to thank Dave Ryan, Lucent Technologies for his 623 invaluable in-depth review of this version of the draft. 625 18. References 627 [Callon] Callon R., et al, "A framework for Multiprotocol Label 628 Switching", draft-ietf-mpls-framework-05.txt. 630 [Fox] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685. 632 [Meyer] Meyer D., "Administratively Scoped IP Multicast", RFC 2365. 634 [Rosen1] Rosen E., et al, "BGP/MPLS VPNs", RFC 2547. 636 [Rosen2] Rosen E., et al, "Multiprotocol Label Switching 637 Architecture", draft-ietf-mpls-arch-06.txt. 639 19. Authors' addresses 641 Karthik Muthukrishnan 642 Lucent Technologies 643 1 Robbins Road 644 Phone: (978) 952-1368 645 Westford, MA 01886 646 Email: mkarthik@lucent.com 648 Andrew Malis 649 Lucent Technologies 650 1 Robbins Road 651 Westford, MA 01886 652 Phone: (978)-952-7414 653 Email: amalis@lucent.com