idnits 2.17.00 (12 Aug 2021) /tmp/idnits44037/draft-nagarajan-ppvpn-generic-reqts-01.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 is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 20) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 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.) ** There are 51 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 18 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 17 has weird spacing: '...ay also distr...' == Line 19 has weird spacing: '...ced, or obsol...' == Line 41 has weird spacing: '... are to be in...' == Line 48 has weird spacing: '...rements for P...' == Line 49 has weird spacing: '...hin the scope...' == (46 more instances...) == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (October 2002) is 7157 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-2026' is mentioned on line 14, but not defined == Missing Reference: 'RFC-2119' is mentioned on line 42, but not defined == Missing Reference: 'RFC3198' is mentioned on line 431, but not defined == Unused Reference: 'RFC2026' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'PPVPN-FR' is defined on line 776, but no explicit reference was found in the text == Unused Reference: 'RFC 3198' is defined on line 795, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 5 errors (**), 0 flaws (~~), 17 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Ananth Nagarajan 3 Expiration Date: April 2003 Sprint 4 Category: Informational (Editor) 5 October 2002 7 Generic Requirements for Provider Provisioned VPN 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of [RFC-2026]. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-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 material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document described generic requirements for Provider Provisioned 32 Virtual Private Networks (PPVPN). The requirements are categorized into 33 service requirements, provider requirements and engineering 34 requirements. These requirements are not specific to any particular 35 type of PPVPN technology, but rather apply to all PPVPN technologies. 37 Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 40 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 41 this document are to be interpreted as described in [RFC-2119]. 43 1. Introduction 45 1.1. Summary for Sub-IP area 47 This document is an output of the design team formed to develop 48 requirements for PPVPNs in the PPVPN working group. As such this 49 work fits within the scope of the PPVPN working group. This 50 document discusses generic PPVPN requirements categorized as 51 service, provider and engineering requirements. These are 52 independent of any particular type of PPVPN technology. 54 1.2. Problem Statement 56 Corporations and other organizations have become increasingly 57 dependent on their networks for tele- and datacommunication. The 58 data communication networks were originally built as Local Area 59 Networks (LAN). Over time the possibility to interconnect the 60 networks on different sites has become more and more important. The 61 connectivity for corporate networks has been supplied by service 62 providers, mainly as FR or ATM connections, but over recent years 63 also as Ethernet and IP-based tunnels. This type of network, 64 interconnecting a number of sites over a shared network 65 infrastructure is called Virtual Private Network (VPN). If the sites 66 belong to the same organization, the VPN is called an Intranet. If 67 the sites belong to different organizations that share a common 68 interest, the VPN is called an Extranet. 70 Customers are looking for service providers to deliver data and 71 telecom connectivity over one or more shared networks,with service 72 level assurances in the form of security, QoS and other parameters. 74 In order to provide isolation between the traffic belonging to 75 different customers, mechanisms such as Layer 2 connections or Layer 76 2/3 tunnels are necessary. When the shared infrastructure is an IP 77 network, the tunneling technologies that are typically used are 78 IPsec, MPLS, L2TP, GRE, IP-in-IP etc. 80 Traditional Internet VPNs have been based on IPsec to provide 81 security over the Internet. Service providers are now beginning to 82 deploy enhanced VPN services that provide features such as service 83 differentiation, traffic management, Layer 2 and Layer 3 84 connectivity, etc. in addition to security. Newer tunneling 85 mechanisms have certain features that allow the service providers to 86 provide these enhanced VPN services. 88 The VPN solutions we define now must be able to accommodate the 89 traditional types of VPNs as well as the enhanced services now being 90 deployed. They need to be able to run in a single service provider's 91 network, as well as between a set of service providers and across the 92 Internet. In doing so the VPNs should not be allowed to violate basic 93 Internet design principles or overload the Internet core routers or 94 accelarate the growths of the Internet routing tables. Specifically, 95 Internet core routers shall not be required to maintain VPN-related 96 information, regardless of whether the Internet routing protocols are 97 used to distribute this information or not. In order to achieve this, 98 the mechanisms used to develop various PPVPN solutions shall be as 99 common as possible with generic Internet infrastructure mechanisms 100 like discovery, signaling, routing and management. At the same time, 101 existing Internet infrastructure mechanisms shall not be overloaded. 103 Another generic requirement from a standardization perspective is to 104 limit the number of different solution approaches to a specific type 105 of VPN to as small a number as possible. 107 1.3. Outline of this document 109 This document describes generic requirements for Provider Provisioned 110 Virtual Private Networks (PPVPN). The document contains several 111 sections, with each set representing a significant aspect of PPVPN 112 requirements. Section 2 lists authors who contributed to this 113 document. Section 3 defines terminology and presents a taxonomy of 114 PPVPN technologies. The taxonomy contains two broad classes, 115 representing Layer 2 and Layer 3 VPNs. Each top level VPN class 116 contains subordinate classes. For 117 example, the Layer 3 VPN class contains a subordinate class of PE- 118 based Layer 3 VPNs. Sections 4, 5, 6 describe generic PPVPN 119 requirements. 121 The requirements are broadly classified under the following 122 categories: 124 1) Service requirements - Service attributes that the customer can 125 observe or measure. For example, does the service forward frames or 126 route datagrams? What security guarantees does the service provide? 127 Availability and stability are key requirements in this category. 129 2) Provider requirements - Characteristics that Service Providers use 130 to determine the cost-effectiveness of a PPVPN service. Scaling and 131 management are examples of Provider requirements. 133 3) Engineering requirements - Implementation characteristics that 134 make service and provider requirements achievable. These can be 135 further classified as: 137 3a) Forwarding plane requirements - e.g., requirements related to 138 router forwarding behavior. 140 3b) Control plane requirements - e.g., requirements related to 141 reachability and distribution of reachability information. 143 3c) Requirements related to the commonality of PPVPN mechanisms with 144 each other and with generic Internet mechanisms. 146 2. Contributing Authors 148 This document was the combined effort of several individuals that 149 were part of the PPVPN requirements design team. A significant set 150 of requirements were directly taken from previous work by the PPVPN 151 WG to develop requirements for Layer 3 PPVPN [L3REQTS]. The 152 following are the authors that contributed to this document: 154 Loa Andersson 155 Ron Bonica 156 Dave McDysan 157 Junichi Sumimoto 158 Muneyoshi Suzuki 159 David Meyer 160 Marco Carugi 161 Yetik Serbest 162 Luyuan Fang 163 Javier Achirica 165 3. Definitions and Taxonomy 167 The terminology used in this document is defined in [TERMINOLOGY]. 169 PPVPN 170 ________________|__________________ 171 | | 172 Layer 2 Layer 3 173 ______|_____ ______|________ 174 | | | | 175 P2P P2M PE-based CE-based 177 (vpws) ____|____ ______|____ | 178 | | | | | 179 VPLS IPLS RFC2547 Virtual IPsec 180 Style Router 182 The figure above presents a taxonomy of PPVPN technologies. Some of 183 the definitions that are not covered in [TERMINOLOGY] are given 184 below: 186 CE-based VPN: A VPN approach in which the shared service provider 187 network does not have any knowledge of the customer VPN. This 188 information is limited to CE equipment. 190 PE-Based VPNs: A layer 3 VPN approach in which a service provider 191 network is used to interconnect customer sites using shared 192 resources. Specifically the PE device maintains VPN state, isolating 193 users of one VPN from users of another VPN. Because the PE device 194 maintains all required VPN state, the CE device may behave as if it 195 were connected to a private network. Specifically, the CE in a PE- 196 based VPN must not require any changes or additional functionality to 197 be connected to a PPVPN instead of a private network. 199 Virtual Router (VR) style: A PE-based VPN approach in which the PE 200 router maintains a complete logical router for each VPN that it 201 supports. Each logical router maintains a unique forwarding table 202 and executes a unique instance of the routing protocols. These VPNs 203 are described in [PPVPN-VR]. 205 RFC 2547 Style: A PE-based VPN approach in which the PE router 206 maintains separate forwarding environment for each VPN and a separate 207 forwarding table for each VPN. In order to maintain multiple 208 forwarding table instances while running only a single routing 209 protocol instance, RFC 2547 style VPNs mark route advertisements with 210 attributes that identify their VPN context. These VPNs are based on 211 the approach described in [RFC2547bis]. 213 4. Service requirements 215 These are the requirements that a customer can observe or measure, in 216 order to verify if the PPVPN service that the Service Provider (SP) 217 provides is satisfactory. 219 4.1. Availability 221 VPN services must have high availability. VPNs that are distributed 222 over several sites require connectivity to be maintained even in the 223 event of network failures or degraded service. 225 This can be achieved via various redundancy techniques such as: 227 1. Physical Diversity 229 A single site connected to multiple CEs (for CE-based PPVPN) or PEs 230 (for PE-based PPVPNs), or different POPs, or even different service 231 providers 233 or 235 2. via tunnel redundancy. 237 4.2. Stability 239 In addition to availability, VPN services must also be stable. 240 Stability is a function of several components such as VPN routing, 241 signaling and discovery mechanisms, in addition to tunnel stability. 242 Stability of the VPN service is directly related to the stability of 243 the mechanisms and protocols used to establish the service. It 244 should also be possible to allow network upgrades and maintenance 245 procedures without impacting the VPN service. 247 4.3. Traffic types 249 VPN services must support unicast (or point to point) traffic and 250 should support any-to-any traffic including multicast and broadcast 251 traffic. In the broadcast model, the network delivers a stream to all 252 members of a subnetwork, regardless of their interest in that stream. 253 In the multicast model, the network delivers a stream to a set of 254 destinations that have registered interest in the stream. All 255 destinations need not belong to the same subnetwork. Multicast is 256 more appropriate for L3 VPNs while broadcast is more appropriate for 257 L2VPNs. It is desirable to support multicast limited in scope to an 258 intranet or extranet. The solution should be able to support a large 259 number of such intranet or extranet specific ulticast groups in a 260 scalable manner. 262 A PPVPN shall support both IPv4 and IPv6 traffic. 264 4.4. Data isolation 266 The PPVPN must support forwarding plane isolation. The network must 267 never deliver user data accross VPN boundaries unless the two VPNs 268 participate in an intranet or extranet. 270 Furthermore, if the provider network receives signaling or routing 271 information from one VPN, it must not reveal that information to 272 another VPN unless the two VPNs participate in an intranet or 273 extranet. 275 4.5. Security 277 A range of security features should be supported by the suite of 278 PPVPN solutions in the form of securing customer flows, providing 279 authentication services for temporary, remote or mobile users, and 280 the need to protect service provider resources involved in supporting 281 a PPVPN[VPN SEC]. Each PPVPN solution should state which security 282 features it supports and how such features can be configured on a per 283 customer basis. Protection against Denial of Service (DoS) attacks is 284 a key component of security mechanisms. Examples of DoS attacks 285 include mail spamming, access connection congestion, TCP SYN attacks, 286 ping attacks and intrusion attempts such as Trojan horse attack. 288 4.5.1. User data security 290 PPVPN solutions that support user data security should use standard 291 methods (e.g., IPsec) to achieve confidentiality, integrity, 292 authentication and replay attack prevention. Such security methods 293 must be configurable between different end points, such as CE-CE, PE- 294 PE, and CE-PE. It is also desirable to configure security on a per- 295 route or per-VPN basis. 297 4.5.2. Access control 299 A PPVPN solution may also have the ability to activate the 300 appropriate filtering capabilities upon request of a customer. A 301 filter provides a mechanism so that access control can be invoked at 302 the point(s) of communication between different organizations 303 involved in an extranet. Access control can be implemented by a 304 firewall, access control lists on routers or similar mechanisms to 305 apply policy-based access control to transit traffic. Access control 306 must also be applicable between CE-CE, PE-PE and CE-PE. 308 4.5.3. Site authentication and authorization 310 A PPVPN solution requires authentication and authorization of the 311 following: 313 - temporary and permanent access for users connecting to sites 314 (authentication and authorization BY the site) 316 - the site itself (authentication and authorization FOR the site) 318 4.5.4. Inter domain security 320 The VPN solution must have appropriate security mechanisms to prevent 321 the different kinds of Distributed Denial of Service (DDoS) attacks 322 mentioned earlier, misconfiguration or unauthorized accesses in inter 323 domain PPVPN connections. 325 4.6. Topology 327 A VPN should support arbitrary, customer agent defined inter-site 328 connectivity, ranging, for example, from hub-and-spoke, partial mesh 329 to full mesh topology. These can actually be different from the 330 topology used by the service provider. To the extent possible, a 331 PPVPN service should be independent of the geographic extent of the 332 deployment. 334 A VPN solution should support multiple VPNs per customer site without 335 requiring additional hardware resources per VPN. It should also 336 support a free mix of L2 and L3 VPNs per customer site. 338 To the extent possible, the PPVPN services should be independent of 339 access network technology. 341 4.7. Addressing (support for private, overlapping addresses) 343 Each customer resource must be identified by an address that is 344 unique within its VPN. It need not be identified by a globally unique 345 address. 347 A VPN service shall be capable of supporting non-IP customer 348 addresses if it is a Layer 2 VPN (e.g., Frame Relay, ATM, Ethernet). 349 Support for non-IP Layer 3 addresses may be desirable in some cases, 350 but is beyond the scope of VPN solutions developed in the IETF, and 351 therefore, this document. 353 4.8. Quality of Service 355 A PPVPN shall be able to support QoS via IETF standardized mechanisms 356 such as Diffserv. Support for best-effort traffic shall be mandatory 357 for all PPVPN types. 359 Note that all cases involving QoS may require that the CE and/or PE 360 perform shaping and/or policing. 362 The need to provide QoS will occur primarily in the access network, 363 since that will often be the bottleneck. This is likely to occur 364 since the backbone effectively statistically multiplexes many users, 365 and is traffic engineerd or includes capacity for restoration and 366 growth. There are two directions of QoS management that must be 367 considered in any PPVPN service regarding QoS: 369 - From the CE across the access network to the PE 370 - From the PE across the access network to CE 372 PPVPN CE and PE devices should be capable of supporting QoS across at 373 least the following subset of access networks, although, to the 374 extent possible, the QoS capability of a PPVPN should be independent 375 of the access network technology : 377 - ATM Virtual Connections (VCs) 378 - Frame Relay Data Link Connection Identifiers (DLCIs) 379 - 802.1d Prioritized Ethernet 380 - MPLS-based access 381 - Multilink Multiclass PPP 382 - QoS-enabled wireless (e.g., LMDS, MMDS) 383 - Cable modem 384 - QoS-enabled Digital Subscriber Line (DSL) 386 Different service models for QoS may be supported. Examples of PPVPN 387 QoS service models are: 389 - Managed access service : Provides QoS on the access connection 390 between CE and the customer facing ports of the PE. No QoS support 391 is required in the provider core network in this case. 393 - Edge-to-edge QoS : Provides QoS across the provider core, either 394 between CE pairs or PE pairs, depending on the tunnel demarcation 395 points. This scenario requires QoS support in the provider core 396 network. 398 4.9. Service Level Agreement and Service Level Specification Monitoring 399 and Reporting 401 A Service Level Specification (SLS) may be defined per access network 402 connection, per VPN, per VPN site, and/or per VPN route. The service 403 provider may define objectives and the measurement interval for at 404 least the SLS using the following Service Level Objective (SLO) 405 parameters: 407 - QoS and traffic parameters for the Intserv flow or Diffserv 408 class [Y.1541] 410 - Availability for the site, VPN, or access connection 412 - Duration of outage intervals per site, route or VPN 414 - Service activation interval (e.g., time to turn up a new site) 416 - Trouble report response time interval 418 - Time to repair interval 420 - Total traffic offered to the site, route or VPN 422 - Measure of non-conforming traffic for the site, route or VPN 424 - Delay and delay variation (jitter) bounds 426 - Packet ordering, at least when transporting L2 services 427 sensitive to reordering (e.g., ATM). 429 The above list contains items from [Y.1241], as well as other items 430 typically part of SLAs for currently deployed VPN services [FRF.13]. 431 See [RFC3198] for generic definitions of SLS, SLA, and SLO. 433 The provider network management system shall measure, and report as 434 necessary, whether measured performance meets or fails to meet the 435 above SLS objectives. 437 The service provider and the customer may negotiate a contractual 438 arrangement that includes a Service Level Agreement (SLA) regarding 439 compensation if the provider does not meet an SLS performance 440 objective. Details of such compensation are outside the scope of 441 this document. 443 4.10. Network Resource Partitioning and Sharing between VPNs 445 Network resources such as memory space, FIB table, bandwidth and CPU 446 processing shall be shared between VPNs. Mechanisms should be 447 provided to prevent any specific VPN from taking up available network 448 resources and causing others to fail. 450 5. Provider requirements 452 This section describes operational requirements for a cost-effective, 453 profitable VPN service offering. 455 5.1. Scalability 457 The scalability for VPN solutions has many aspects. The list below is 458 intended to comprise of the aspects that PPVPN solutions should 459 address. Clearly these aspects in absolute figures are very 460 different for different types of VPNs - i.e., a point to point 461 service has only two sites, while a VPLS or L3VPN may have a larger 462 number of sites. It is also important to verify that PPVPN solutions 463 not only scales on the high end, a VPN with three sites and three 464 users should be as viable as a VPN with hundreds of sites and 465 thousands of users. 467 Terminology: 469 Site: a geographical location with one or more users or one or more 470 servers or a combination of servers and users. 472 User: the end user equipment (hosts), e.g., a workstation. 474 Note: Further discussion on Section 5.1.1 and 5.1.2 is needed. 476 5.1.1. Service Provider Capacity Sizing Projections 478 A PPVPN solution should be scalable to support a very large number of 479 VPNs per Service Provider network. The estimate is that a large 480 service provider will require support for on the order of 10,000 481 VPNs within four years. 483 A PPVPN solution should be scalable to support of a wide range of 484 number of site interfaces per VPN, depending on the size and/or 485 structure of the customer organization. The number of site 486 interfaces should range from a few site interfaces to over 50,000 487 site interfaces per VPN. 489 A PPVPN solution should be scalable to support of a wide range of 490 number of routes per VPN. The number of routes per VPN may range 491 from just a few to the number of routes exchanged between ISPs (on 492 the order of 100,000). The high end number is especially true 493 considering the fact that many large ISPs may provide VPN services to 494 smaller ISPs or large corporations. Typically, the number of routes 495 per VPN are twice the number of site interfaces or larger. 497 A PPVPN solution should support high values of the frequency of 498 configuration setup and change, e.g., for real-time provisioning of 499 an on-demand videoconferencing VPN or addition/deletion of sites. 501 Approaches should articulate scaling and performance limits for more 502 complex deployment scenarios, such as inter-AS(S) VPNs and carriers' 503 carrier. Approaches should also describe other dimensions of 504 interest, such as capacity requirements or limits, number of 505 interworking instances supported as well as any scalability 506 implications on management systems. 508 A PPVPN solution should support a large number of customer interfaces 509 on a single PE (for PE-based PPVPN) or CE (for CE-based PPVPN) with 510 current Internet protocols. 512 5.1.2. VPN Scalability aspects 514 This section describes the metrics for scaling PPVPN solutions, 515 points out some of the scaling differences between L2 and L3 VPNs. 516 Further discussion on service provider sizing projections are in 517 Section 5.1.2. 519 5.1.2.1. Number of users per VPN 521 The number of users per VPN is the combination of servers and hosts 522 connected to the VPN. It needs to scale from a handful to extremely 523 high numbers. 525 Clearly there is a possible trade off between the number of users and 526 the VPN technology chosen. 528 L3 VPNs must scale from 2 users per VPN to O(10^5) users per VPN. L2 529 VPNs must scale from 2 users to a few hundred. 531 5.1.2.2. Number of users per site 533 The number of users per site follows the same logic as for users per 534 VPN. Further, it must be possible to have single user sites connected 535 to the same VPN as very large sites are connected to. 537 L3 VPNs must scale from 1 user per site to thousands of users per 538 site. L2 VPNs must scale from 1 user to a few hundred per site. 540 5.1.2.3. Number of sites per VPN 542 The number of sites per VPN is clearly limited by the number of users 543 for a L2 VPN. The largest number of sites in a L2VPN would be equal 544 to the largest number of users, distributed one per site. For L3 VPNs 545 number of sites per VPN should scale from 2 to very large numbers 546 that are usually limited by router memory. 548 5.1.2.4. Number of PEs 550 The number of PEs that supports the same set of VPNs, i.e., the 551 number of PEs that needs to directly exchange information on VPN de- 552 multiplexing information is clearly a scaling factor. This number is 553 driven by the type of VPN service, and also by whether the service is 554 within a single AS/domain or involves a multi-SP or multi-AS network. 556 5.1.2.5. Number of sites per PE 558 The number of sites per PE needs to be discussed based on several 559 different scenarios. On the one hand there is a limitation to the 560 number of customer facing interfaces that the PE can support. On the 561 other hand the access network may aggregate several sites connected 562 on comparatively low bandwidth on to one single high bandwidth 563 interface on the PE. The scaling point here is that the PE must be 564 able to support a few or even a single site on the low end and 565 O(10^4) sites on the high end. Various PPVPN solutions may be 566 evaluated based on this requirement. 568 5.1.2.6. Number of VPNs in the network 570 The number of sites in a network should not be a scaling issue. The 571 number of VPNs should scale linearly with the size of the access 572 network and with the number of PEs. As mentioned in Section 5.1.1, 573 the number of VPNs in the network should be O(10^4). 575 5.1.2.7. Number of VPNs per PE 577 This is a function of number of sites per PE and number of VPNs per 578 site. It is estimated that the number of VPNs needs to be at least 579 one order of magnitude higher than the number of sites per PE. 581 5.1.2.8. Number of VPNs per site 583 On a customer's main site it is fully conceivable that the number of 584 VPNs could be fairly large, both service diversification and 585 separation of different work groups contributes to this. It is 586 possible that one customer will run up to O(100) VPNs. 588 5.1.2.9. Number of addresses per VPN 590 Since any VPN solution shall support private customer addresses, the 591 number of addresses supported for a L3 VPN needs to scale from very 592 few (for smaller customers) to very large numbers seen in typical SP 593 backbones. The high end is especially true considering that many Tier 594 1 SPs may provide VPN services to Tier 2 SPs or to large 595 corporations. For a L2 VPN this number would be on the order of 596 addresses supported in typical native Layer 2 backbones. 598 5.1.2.10. Number of addresses per PE 600 This is a function of the number of VPNs per site and the number of 601 addresses per site. 603 5.1.3. Solution-Specific Metrics 605 Each PPVPN solution shall document its scalability characteristics in 606 quantitative terms. Two examples are provided below as an 607 illustration. 609 The following example applies to the number of tunnels necessary in 610 various devices in the network. In a PE-based VPN, edge-to-edge 611 tunnels (PE-to-PE) need to be established, while in a CE-based VPN, 612 end-to-end tunnels between pairs of CEs are necessary. Therefore, 613 fewer tunnels need to be maintained in a PE-based solution and 614 scalability could be improved over that of CE-based VPNs. The other 615 tradeoff is that in a PE-based solution, the CE is simple at the 616 expense of complex PE devices, while on the other hand, in a CE- 617 based solution, the PE devices remain simple while the CE devices are 618 more complex. 620 A scalable PE-based solution should quantify the amount of state that 621 a PE and P device must support. This should be stated in terms of 622 the total number of VPNs and site interfaces supported by the 623 service provider. Ideally, all VPN-specific state should be 624 contained in the PE device for a PE-based VPN. Similarly, all VPN- 625 specific state should be contained in the CE device for a CE-based 626 VPN. In all cases, the backbone routers (P devices) shall not 627 maintain VPN-specific state as far as possible. 629 5.2. Management 631 A service provider must have a means to view the topology, 632 operational state, order status, and other parameters associated with 633 each customer's VPN. Furthermore, the service provider must have a 634 means to view the underlying logical and physical topology, 635 operational state, provisioning status, and other parameters 636 associated with the equipment providing the VPN service(s) to its 637 customers. 639 VPN devices should provide standards-based management interfaces 640 wherever feasible. 642 Service Provider Network Management System (NMS) requirements mainly 643 fall in the traditional fault, configuration, accounting, 644 performance, and security (FCAPS) management categories. These 645 requirements are available in detail in [Y.1311.1]. 647 6. Engineering requirements 649 These requirements are driven by implementation characteristics that 650 make service and provider requirements achievable. 652 6.1. Forwarding plane requirements 654 VPN solutions should not pre-suppose or preclude the use of IETF 655 developed tunneling techniques such as IP-in-IP, L2TP, GRE, MPLS or 656 IPsec. The separation of VPN solution and tunnels will facilitate 657 adaptability with extensions to current tunneling techniques or 658 development of new tunneling techniques. It should be noted that the 659 choice of the tunneling techniques may impact the service 660 capabilities of the VPN solution. 662 For Layer 2 VPNs, solutions should utilize the encapsulation 663 techniques defined by PWE3, and should not impose any new 664 requirements on these techniques. 666 PPVPN solutions must not impose any restrictions on the backbone 667 traffic engineering and management techniques. Conversely, backbone 668 engineering and management techniques must not affect the basic 669 operation of a PPVPN, apart from impacting the SLA/SLS guarantees 670 associated with the service. 672 By definition, VPN traffic should be segregated from each other, and 673 from non-VPN traffic in the network. After all, VPNs are a means of 674 dividing a physical network into several logical (virtual) networks. 675 VPN traffic separation should be done in a scalable fashion. However, 676 safeguards should be made available against misbehaving VPNs to not 677 affect the network and other VPNs. 679 VPN solution should not impose any hard limit on the number of VPNs 680 provided in the network. 682 6.2. Control plane requirements 684 The plug and play feature of a VPN solution with minimum 685 configuration requirements is an important consideration. The VPN 686 solutions should have mechanisms for protection against customer 687 interface and/or routing instabilities so that they do not impact 688 other customers' services. 690 A VPN should be provisioned with minimum number of steps. For 691 instance, a VPN need not be configured in every PE. For this to be 692 accomplished, an auto-configuration and an auto-discovery protocol, 693 which should be common to all VPN solutions, should be defined. 694 However, these mechanisms should not affect the cost, scalability or 695 stability of a service by being overly complex, or by increasing 696 layers in the protocol stack. 698 6.3. Control Plane Containment 700 The PPVPN control plane must include a mechanism through which the 701 service provider can filter PPVPN related control plane information 702 as it passes between Autonomous Systems. For example, if a service 703 provider supports a PPVPN offering, but the service provider's 704 neighbors do not participate in that offering, the service provider 705 should not leak PPVPN control information into neighboring networks. 706 Neighboring networks must be equipped with mechanisms that filter 707 this information should the service provider leak it. 709 6.4. Requirements related to commonality of PPVPN mechanisms with each 710 other and with generic Internet mechanisms 712 As far as possible, the mechanisms used to establish a VPN service 713 should re-use well-known IETF protocols as far as possible, limiting 714 the need to define new protocols from scratch. It should, however, be 715 noted that the use of Internet mechanisms for the establishment and 716 running of an Internet-based VPN service, shall not affect the 717 stability, robustness, and scalability of the Internet or Internet 718 services. In other words, these mechanisms should not conflict with 719 the architectural principles of the Internet, nor should it put at 720 risk the existing Internet systems. For example, IETF-developed 721 routing protocols should be used for routing of L3 PPVPN traffic, 722 without adding VPN-specific state to the Internet routers. Similarly, 723 familiar L2 technologies should be used in VPNs offering L2 services, 724 without imposing risks to the Internet routers. A solution must be 725 implementable without requiring to add additional funcionality to the 726 devices in a network. 728 In addition to commonality with generic Internet mechanisms, 729 infrastructure mechanisms used in different PPVPN solutions (both L2 730 and L3), e.g., discovery, signaling, routing and management, should 731 be as common as possible. 733 6.5. Interoperability 735 Each technical solution is expected to be based on interoperable 736 Internet standards. 738 Multi-vendor interoperability at network element, network and service 739 levels among different implementations of the same technical solution 740 should be ensured (that will likely rely on the completeness of the 741 corresponding standard). This is a central requirement for SPs and 742 customers. 744 The technical solution must be multi-vendor interoperable not only 745 within the SP network infrastructure, but also with the customer's 746 network equipment and services making usage of the PPVPN service. 748 Customer access connections to a PPVPN solution may be different at 749 different sites (e.g., Frame Relay on one site and Ethernet on 750 another) 752 Interconnection of a L2VPN to a L3VPN as if it were a customer site 753 shall be supported. 755 Inter-domain interoperability - It should be possible to deploy a 756 PPVPN solution across domains, Autonomous Systems, or the Internet. 758 7. Security Considerations 760 This document does not have any security considerations other than 761 the security requirements described in Section 4.5. 763 8. References 765 8.1. Normative References 767 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 768 3", BCP 9, RFC 2026, October 1996. 769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 770 Requirement Levels", BCP 14, RFC 2119, March 1997 772 8.2. Non-normative References 774 [TERMINOLOGY] Andersson, L., Madsen, T., "Terminology for Provider 775 Provisioned Virtual Private Networks", work in progress 776 [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider 777 Provisioned Virtual Private Networks ", work in progress 778 [PPVPN-VR] Ould-Brahim, H., Gleeson, B., et al. "Network based IP 779 VPN Architecture using Virtual Routers", work in 780 progress 781 [L3REQTS] Carugi, M., McDysan, D. et al., "Service Requirements 782 for Layer 3 Provider Provisioned Virtual Private 783 Networks", work in progress 784 [RFC2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work 785 in progress. 786 [Y.1241] "IP Transfer Capability for the support of IP based 787 Services", Y.1241 ITU-T Draft Recommendation, March 2000 788 [Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS 789 architecture",Y.1311.1 ITU-T Recommendation, May 2001 790 (http://ppvpn.francetelecom.com/ituRelated.html) 791 [Y.1311] Knightson, K. (editor), " Network based IP VPN Service 792 - Generic Framework and Service Requirements ", Y.1311 793 ITU-T Draft Recommendation, May 2001 794 (http://ppvpn.francetelecom.com/ituRelated.html) 795 [RFC 3198] A. Westerinen et al, "Terminology for Policy-Based 796 Management," November, 2001. 797 [VPN SEC] J. De Clercq et al, "Considerations about possible 798 security extensions to BGP/MPLS VPN," work in progress. 799 [FRF.13] Frame Relay Forum, "Service Level Definitions 800 Implementation Agreement," August, 1998. 801 [Y.1541] "Network Performance Objectives for IP-based 802 Services," Y.1541, ITU-T Recommendation. 804 9. Acknowledgements 806 This work was done in consultation with the entire design team for 807 PPVPN requirements. A lot of the text was adapted from the Layer 3 808 requirements document produced by Layer 3 requirements design team. 809 The authors would also like to acknowledge the constructive feedback 810 from Alex Zinin. 812 10. Editor's Address 814 Ananth Nagarajan 815 Sprint 816 6220 Sprint Parkway 817 Overland Park, KS 66251 818 USA 819 E-mail: ananth.nagarajan@mail.sprint.com 821 11. Full Copyright Statement 823 Copyright (C) The Internet Society (2000). All Rights Reserved. 825 This document and translations of it may be copied and furnished to 826 others, and derivative works that comment on or otherwise explain it 827 or assist in its implementation may be prepared, copied, published 828 and distributed, in whole or in part, without restriction of any 829 kind, provided that the above copyright notice and this paragraph are 830 included on all such copies and derivative works. However, this 831 document itself may not be modified in any way, such as by removing 832 the copyright notice or references to the Internet Society or other 833 Internet organizations, except as needed for the purpose of 834 developing Internet standards in which case the procedures for 835 copyrights defined in the Internet Standards process must be 836 followed, or as required to translate it into languages other than 837 English. 839 The limited permissions granted above are perpetual and will not be 840 revoked by the Internet Society or its successors or assigns. 842 This document and the information contained herein is provided on an 843 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 844 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 845 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 846 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 847 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.