idnits 2.17.1 draft-ietf-l3vpn-requirements-02.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2563 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 2 instances of too long lines in the document, the longest one being 1 character 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 241 has weird spacing: '...ents in commo...' == Line 1165 has weird spacing: '... sizing and s...' == Line 1757 has weird spacing: '...This is a...' == Line 2080 has weird spacing: '...en that devic...' == Line 2099 has weird spacing: '... policy infor...' == (2 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: QoS policies MUST not be impacted by security mechanisms. For example, Diffserv policies MUST not be impacted by the use of IPSec tunnels, using the mechanisms explained in RFC 2983. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Ideally, the choice of a SP's IGP SHOULD not depend on the routing protocol(s) used between PE and CE routers in a PE-based VPN. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 6.8 Isolation of Traffic and Routing The internal structure of a L3VPN network SHOULD not be visible to outside networks (i.e., the Internet or any connected VPN). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-2026' is mentioned on line 16, but not defined == Missing Reference: 'RFC-2119' is mentioned on line 63, but not defined == Missing Reference: 'PPVPN-GR' is mentioned on line 1473, but not defined == Missing Reference: 'RFC2547bis' is mentioned on line 200, but not defined ** Obsolete undefined reference: RFC 2547 (Obsoleted by RFC 4364) == Missing Reference: 'IPsec-PPVPN' is mentioned on line 201, but not defined == Missing Reference: 'RFC3377' is mentioned on line 543, but not defined ** Obsolete undefined reference: RFC 3377 (Obsoleted by RFC 4510) == Missing Reference: 'RFC2251' is mentioned on line 543, but not defined ** Obsolete undefined reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) == Missing Reference: 'VPNSEC' is mentioned on line 2140, but not defined == Missing Reference: 'RFC2385' is mentioned on line 1479, but not defined ** Obsolete undefined reference: RFC 2385 (Obsoleted by RFC 5925) == Unused Reference: 'RFC 3809' is defined on line 2169, but no explicit reference was found in the text == Unused Reference: 'RFC 3377' is defined on line 2171, but no explicit reference was found in the text == Unused Reference: 'RFC 1918' is defined on line 2174, but no explicit reference was found in the text == Unused Reference: 'RFC 2026' is defined on line 2176, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 2178, but no explicit reference was found in the text == Unused Reference: 'RFC 2251' is defined on line 2189, but no explicit reference was found in the text == Unused Reference: 'RFC 2661' is defined on line 2196, but no explicit reference was found in the text == Unused Reference: 'RFC 2685' is defined on line 2198, but no explicit reference was found in the text == Unused Reference: 'RFC 2983' is defined on line 2200, but no explicit reference was found in the text == Unused Reference: 'RFC 3031' is defined on line 2202, but no explicit reference was found in the text == Unused Reference: 'RFC 3270' is defined on line 2206, but no explicit reference was found in the text == Unused Reference: '2547bis' is defined on line 2211, but no explicit reference was found in the text == Unused Reference: '2917bis' is defined on line 2213, but no explicit reference was found in the text == Unused Reference: 'IPSEC-PPVPN' is defined on line 2236, but no explicit reference was found in the text == Unused Reference: 'L2 MPLS' is defined on line 2238, but no explicit reference was found in the text == Unused Reference: 'L3VPN-SEC' is defined on line 2248, but no explicit reference was found in the text == Unused Reference: 'NBVPN-FR' is defined on line 2251, but no explicit reference was found in the text == Unused Reference: 'QPIM' is defined on line 2259, but no explicit reference was found in the text == Unused Reference: 'RFC 2547' is defined on line 2261, but no explicit reference was found in the text == Unused Reference: 'RFC 2975' is defined on line 2265, but no explicit reference was found in the text == Unused Reference: 'VPN DISC' is defined on line 2271, but no explicit reference was found in the text == Unused Reference: 'VPN SEC' is defined on line 2280, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 10 errors (**), 0 flaws (~~), 43 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT M. Carugi 2 Internet Engineering Task Force Nortel Networks 3 Document: D. McDysan 4 draft-ietf-l3vpn-requirements-02.txt MCI 5 July 2004 (Co-Editors) 6 Category: Informational 7 Expires: January 2005 9 Service requirements for Layer 3 Virtual Private Networks: 10 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026 ([RFC-2026]). 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 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 This document is a product of the IETF's Layer 3 Virtual Private 34 Network (l3vpn) working group. Comments should be addressed to WG's 35 mailing list at l3vpn@ietf.org. The charter for l3vpn may be found 36 at http://www.ietf.org/html.charters/l3vpn-charter.html 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 39 Distribution of this memo is unlimited. 41 Abstract 43 This document provides requirements for Layer 3 Virtual Private 44 Networks (L3VPNs). It identifies requirements applicable to a number 45 of individual approaches that a Service Provider may use for the 46 provisioning of a VPN service. This document expresses a service 47 provider perspective, based upon past experience of IP-based service 48 offerings and the ever-evolving needs of the customers of such 49 services. Toward this end, it first defines terminology and states 50 general requirements. Detailed requirements are expressed from a 51 customer as well as a service provider perspective. 53 Carugi, McDysan et al 1 55 Service requirements for Layer 3 PPVPNs July 2004 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 61 this document are to be interpreted as described in RFC 2119 ([RFC- 62 2119]). 64 Table of Contents 65 1 Introduction....................................................5 66 1.1 Scope of this document.........................................5 67 1.2 Outline........................................................6 68 2 Contributing Authors............................................6 69 3 Definitions.....................................................6 70 3.1 Virtual Private Network........................................6 71 3.2 Users, Sites, Customers and Agents.............................7 72 3.3 Intranets, Extranets, and VPNs.................................7 73 3.4 Networks of Customer and Provider Devices......................7 74 3.5 Access Networks, Tunnels, and Hierarchical Tunnels.............8 75 3.6 Use of Tunnels and roles of CE and PE in L3 VPNs...............9 76 3.6.1 PE-Based Layer 3 VPNs and Virtual Forwarding Instances....9 77 3.6.2 CE-Based L3VPN Tunnel Endpoints and Functions............10 78 3.7 Customer and Provider Network Management......................11 79 4 Service Requirements Common to Customers and Service Providers.12 80 4.1 Isolated Exchange of Data and Routing Information.............12 81 4.2 Addressing....................................................12 82 4.3 Quality of Service............................................12 83 4.3.1 QoS Standards............................................13 84 4.3.2 Service Models...........................................14 85 4.4 Service Level Specification and Agreements....................14 86 4.5 Management....................................................15 87 4.6 Interworking..................................................15 88 5 Customer Requirements..........................................15 89 5.1 VPN Membership (Intranet/Extranet)............................15 90 5.2 Service Provider Independence.................................16 91 5.3 Addressing....................................................16 92 5.4 Routing Protocol Support......................................16 93 5.5 Quality of Service and Traffic Parameters.....................16 94 5.5.1 Application Level QoS Objectives.........................16 95 5.5.2 DSCP Transparency........................................17 96 5.6 Service Level Specification/Agreement.........................17 97 5.7 Customer Management of a VPN..................................18 98 5.8 Isolation.....................................................18 99 5.9 Security......................................................18 100 5.10 Migration Impact..............................................19 101 5.11 Network Access................................................19 102 5.11.1 Physical/Link Layer Technology...........................19 103 5.11.2 Temporary Access.........................................19 104 5.11.3 Sharing of the Access Network............................20 105 5.11.4 Access Connectivity......................................20 106 5.12 Service Access................................................22 107 5.12.1 Internet Access..........................................22 108 5.12.2 Hosting, Application Service Provider....................22 110 Carugi, McDysan et al Informational - Expires January 2005 2 112 Service requirements for Layer 3 PPVPNs July 2004 114 5.12.3 Other Services...........................................22 115 5.13 Hybrid VPN Service Scenarios..................................22 116 6 Service Provider Network Requirements..........................23 117 6.1 Scalability...................................................23 118 6.2 Addressing....................................................23 119 6.3 Identifiers...................................................23 120 6.4 Discovering VPN Related Information...........................24 121 6.5 SLA and SLS Support...........................................24 122 6.6 Quality of Service (QoS) and Traffic Engineering..............25 123 6.7 Routing.......................................................25 124 6.8 Isolation of Traffic and Routing..............................26 125 6.9 Security......................................................26 126 6.9.1 Support for Securing Customer Flows......................26 127 6.9.2 Authentication Services..................................27 128 6.9.3 Resource Protection......................................27 129 6.10 Inter-AS (SP)VPNs.............................................28 130 6.10.1 Routing Protocols........................................28 131 6.10.2 Management...............................................28 132 6.10.3 Bandwidth and QoS Brokering..............................29 133 6.10.4 Security Considerations..................................29 134 6.11 L3VPN Wholesale...............................................29 135 6.12 Tunneling Requirements........................................30 136 6.13 Support for Access and Backbone Technologies..................30 137 6.13.1 Dedicated Access Networks................................31 138 6.13.2 On-Demand Access Networks................................31 139 6.13.3 Backbone Networks........................................31 140 6.14 Protection, Restoration.......................................31 141 6.15 Interoperability..............................................32 142 6.16 Migration Support.............................................32 143 7 Service Provider Management Requirements.......................33 144 7.1 Fault management..............................................33 145 7.2 Configuration Management......................................34 146 7.2.1 Configuration Management for PE-Based VPNs...............35 147 7.2.2 Configuration management for CE-based VPN................35 148 7.2.3 Provisioning Routing.....................................35 149 7.2.4 Provisioning Network Access..............................35 150 7.2.5 Provisioning Security Services...........................36 151 7.2.6 Provisioning VPN Resource Parameters.....................36 152 7.2.7 Provisioning Value-Added Service Access..................36 153 7.2.8 Provisioning Hybrid VPN Services.........................37 154 7.3 Accounting....................................................37 155 7.4 Performance Management........................................38 156 7.4.1 Performance Monitoring...................................38 157 7.4.2 SLA and QoS management features..........................38 158 7.5 Security Management...........................................38 159 7.5.1 Resource Access Control....................................38 160 7.5.2 Authentication...........................................39 161 7.6 Network Management Techniques.................................39 162 8 Security Considerations........................................40 163 9 Acknowledgements...............................................40 164 10 References.....................................................41 165 10.1 Normative References..........................................41 167 Carugi, McDysan et al Informational - Expires January 2005 3 169 Service requirements for Layer 3 PPVPNs July 2004 171 10.2 Non-normative References......................................41 172 11 Authors' address...............................................43 174 Carugi, McDysan et al Informational - Expires January 2005 4 176 Service requirements for Layer 3 PPVPNs July 2004 178 1 Introduction 179 This section describes the scope and outline of the document. 181 1.1 Scope of this document 182 This document provides requirements specific to Layer 3 Virtual 183 Private Networks (L3VPN) (requirements that are generic to L2 and L3 184 VPNs are contained in [PPVPN-GR]). 185 This document identifies requirements that may apply to one or more 186 individual approaches that a Service Provider may use for the 187 provisioning of a Layer 3 (e.g., IP) VPN service. It makes use of 188 the terminology and common components for Layer 3 VPNs defined in 189 [L3VPN-FR] and of the generic VPN terminology defined in [PPVPN- 190 TERM]. 192 The specification of technical means to provide L3VPN services is 193 outside the scope of this document. Other documents, such as the L3 194 VPN framework document [L3VPN-FR] and several sets of documents, one 195 set per each individual technical approach for providing L3VPN 196 services, are intended to cover this aspect. 198 Technical approaches targeted by this document include the network- 199 based (PE-based) L3 VPN category (aggregated routing VPNs 200 [RFC2547bis] and virtual routers [PPVPN-VR]) and the CE-based L3 201 VPNs category [CE-PPVPN][IPsec-PPVPN]. The document distinguishes 202 L3VPN categories as to where the endpoints of tunnels exist as 203 detailed in the L3VPN framework document [L3VPN-FR]. Terminology 204 regarding whether equipment faces a customer or the service provider 205 network is used to define the various types of L3 VPN solutions.> 207 This document is intended as a "checklist" of requirements providing 208 a consistent way to evaluate and document how well each individual 209 approach satisfies specific requirements. The applicability 210 statement documents for each individual approach should present the 211 results of this evaluation. It is not the intent of this document to 212 state a comparison of one approach versus another. 214 This document provides requirements from several points of view. It 215 begins with some considerations from a common customer and service 216 provider point of view not covered in the generic provider 217 provisioned VPN requirement document [PPVPN-GR], followed by a 218 customer perspective, and concludes with specific needs of a Service 219 Provider (SP). 221 The following L3VPN deployment scenarios are considered within this 222 document: 224 1. Internet-wide: VPN sites attached to arbitrary points in 225 the Internet 227 2. Single SP/single AS: VPN sites attached to the network of a 228 single provider within the scope of a single AS 230 Carugi, McDysan et al Informational - Expires January 2005 5 232 Service requirements for Layer 3 PPVPNs July 2004 234 3.Single SP/multiple ASs: VPN sites attached to the network 235 of a single provider consisting of multiple ASs 237 4.Cooperating SPs: VPN sites attached to networks of different 238 providers that cooperate with each other to provide the VPN 239 service 241 The above deployment scenarios have many requirements in common. 242 These common requirements include SP requirements for security, 243 privacy, manageability, interoperability and scalability, including 244 service provider projections for number, complexity, and rate of 245 change of customer VPNs over the next several years. When 246 requirements apply to a specific deployment scenario, the above 247 terminology is used to state the context of those particular 248 requirements. 250 1.2 Outline 251 The outline of the rest of the document is as follows. Section 2 252 mentions the contributing authors. Section 3 provides definitions of 253 terms and concepts. Section 4 provides requirements that are common 254 to both customers and service providers and are not covered in the 255 generic provider provisioned VPN requirement document [PPVPN-GR]. 256 Section 5 states requirements from a customer perspective. Section 6 257 states network requirements from a service provider perspective. 258 Section 7 states service provider management requirements. Section 8 259 describes security considerations. Section 9 lists acknowledgements. 260 Section 10 provides a list of references cited herein. Section 11 261 lists the authors' addresses. 263 2 Contributing Authors 264 This document is the combined effort of the two co-editors and the 265 following contributing authors: 266 Luyuan Fang 267 Ananth Nagarajan 268 Junichi Sumimoto 269 Rick Wilder 271 3 Definitions 272 This section provides the definition of terms and concepts used 273 throughout the document. Terminology used herein is taken from 274 [PPVPN-TERM] and [L3VPN-FR]. 276 3.1 Virtual Private Network 278 "L3 Virtual Private Network" (L3 VPN) refers to the L3 communication 279 between a set of sites, making use of a shared network 280 infrastructure. 282 "Provider Provisioned VPN" (PPVPN) refers to VPNs for which the 283 service provider participates in management and provisioning of the 284 VPN. 286 Carugi, McDysan et al Informational - Expires January 2005 6 288 Service requirements for Layer 3 PPVPNs July 2004 290 3.2 Users, Sites, Customers and Agents 291 User: A user is an entity (e.g., a human being using a host, a 292 server, or a system) that has been authorized to use a VPN service. 294 Site: A site is a set of users that have mutual L3 (i.e., IP) 295 reachability without use of a specific service provider network. A 296 site may consist of a set of users that are in geographic proximity. 297 Note that a topological definition of a site (e.g., all users at a 298 specific geographic location) may not always conform to this 299 definition. For example, two geographic locations connected via 300 another provider's network would also constitute a single site since 301 communication between the two locations does not involve the use of 302 the service provider offering the L3 VPN service. 304 Customer: A single organization, corporation, or enterprise that 305 administratively controls a set of sites. 307 Agent: A set of users designated by a customer who has the 308 authorization to manage a customer's VPN service offering. 310 3.3 Intranets, Extranets, and VPNs 312 Intranet: An intranet restricts communication to a set of sites that 313 belong to one customer. An example is branch offices at different 314 sites that require communication to a headquarters site. 316 Extranet: An extranet allows the specification of communication 317 between a set of sites that belong to different customers. In other 318 words, two or more organizations have access to a specified set of 319 each other's sites. Examples of an extranet scenario include 320 multiple companies cooperating in joint software development, a 321 service provider having access to information from the vendors' 322 corporate sites, different companies, or universities participating 323 in a consortium. An extranet often has further restrictions on 324 reachability, for example, at a host and individual transport level. 326 Note that an intranet or extranet can exist across a single service 327 provider network with one or more ASs, or across multiple service 328 provider networks. 330 L3 Virtual Private Network (L3 VPN): An alternative definition of 331 VPN refers to a specific set of sites as either an intranet or an 332 extranet that have been configured to allow communication. Note that 333 a site is a member of at least one VPN, and may be a member of many 334 VPNs. 336 3.4 Networks of Customer and Provider Devices 337 L3VPNs are composed of the following types of devices. 339 Customer Edge (CE) device: A CE device faces the users at a customer 340 site. The CE has an access connection to a PE device. It may be a 342 Carugi, McDysan et al Informational - Expires January 2005 7 344 Service requirements for Layer 3 PPVPNs July 2004 346 router or a switch that allows users at a customer site to 347 communicate over the access network with other sites in the VPN. In 348 a CE-based L3VPN, as intended in this document (provider provisioned 349 CE-based VPN), the service provider manages (at least partially) the 350 CE device. 352 Provider Edge (PE) device: A PE device faces the provider network on 353 one side and attaches via an access connection over one or more 354 access networks to one or more CE devices. It participates in the 355 Packet Switched Network (PSN) in performing routing and forwarding 356 functions. 358 Note that the definitions of Customer Edge and Provider Edge do not 359 necessarily map to the physical deployment of equipment on customer 360 premises or a provider point of presence. 362 Provider (P) device: A device within a provider network that 363 interconnects PE (or other P) devices, but does not have any direct 364 attachment to CE devices. The P router does not keep VPN state and 365 is VPN un-aware [PPVPN-TERM]. 367 Packet Switched Network (PSN): A (IP or MPLS) network through which 368 the tunnels supporting the VPN services are set up [PPVPN-TERM]. 370 Service Provider (SP) network: An SP network is a set of 371 interconnected PE and P devices administered by a single service 372 provider in one or more ASs. 374 3.5 Access Networks, Tunnels, and Hierarchical Tunnels 375 VPNs are built between CEs using access networks, tunnels, and 376 hierarchical tunnels across a PSN. 378 Access connection: An access connection provides connectivity 379 between a CE and a PE. This includes dedicated physical circuits, 380 virtual circuits, such as Frame Relay, ATM, Ethernet (V)LAN, or IP 381 tunnels (e.g., IPsec, L2TP). 383 Access network: An access network provides access connections 384 between CE and PE devices. It may be a TDM network, L2 network 385 (e.g. FR, ATM, and Ethernet), or an IP network over which access is 386 tunneled (e.g., using L2TP]). 388 Tunnel: A tunnel between two entities is formed by encapsulating 389 packets within another encapsulating header for purpose of 390 transmission between those two entities in support of a VPN 391 application. Examples of protocols commonly used for tunneling are: 392 GRE, IPsec, IP-in-IP tunnels, and MPLS. 394 Hierarchical Tunnel: Encapsulating one tunnel within another forms a 395 hierarchical tunnel. The innermost tunnel protocol header defines a 396 logical association between two entities (e.g., between CEs or PEs) 398 Carugi, McDysan et al Informational - Expires January 2005 8 400 Service requirements for Layer 3 PPVPNs July 2004 402 [VPN TUNNEL]. Note that the tunneling protocols need not be the same 403 at different levels in a hierarchical tunnel. 405 3.6 Use of Tunnels and roles of CE and PE in L3 VPNs 406 This section summarizes the point where tunnels terminate and the 407 functions implemented in the CE and PE devices that differentiate 408 the two major categories of L3 VPNs for which requirements are 409 stated, namely PE-based and CE-based L3 VPNs. See the L3VPN 410 framework document for more detail [L3VPN-FR]. 412 3.6.1 PE-Based Layer 3 VPNs and Virtual Forwarding Instances 413 In a PE-based layer 3 VPN service, a customer site receives IP layer 414 (i.e., layer 3) service from the SP. The PE is attached via an 415 access connection to one or more CEs. The PE performs forwarding of 416 user data packets based on information in the IP layer header, such 417 as an IPv4 or IPv6 destination address. The CE sees the PE as a 418 layer 3 device such as an IPv4 or IPv6 router. 420 Virtual Forwarding Instance (VFI): In a PE-based layer 3 VPN 421 service, the PE contains a VFI for each L3 VPN that it serves. The 422 VFI terminates tunnels for interconnection with other VFIs and also 423 terminates access connections for accommodating CEs. VFI contains 424 information regarding how to forward data received over the CE-PE 425 access connection to VFIs in other PEs supporting the same L3 VPN. 426 The VFI includes the router information base and the forwarding 427 information base for a L3 VPN [L3VPN-FR]. A VFI enables router 428 functions dedicated to serving a particular VPN, such as separation 429 of forwarding and routing and support for overlapping address 430 spaces. Routing protocols in the PEs and the CEs interact to 431 populate the VFI. 433 The following narrative and figures provide further explanation of 434 the way PE devices use tunnels and hierarchical tunnels. Figure 3.1 435 illustrates the case where a PE uses a separate tunnel for each VPN. 436 As shown in the figure, the tunnels provide communication between 437 the VFIs in each of the PE devices. 439 +----------+ +----------+ 440 +-----+ |PE device | |PE device | +-----+ 441 | CE | | | | | | CE | 442 | dev | Access | +------+ | | +------+ | Access | dev | 443 | of | conn. | |VFI of| | Tunnel | |VFI of| | conn. | of | 444 |VPN A|----------|VPN A |==================|VPN A |----------|VPN A| 445 +-----+ | +------+ | | +------+ | +-----+ 446 | | | | 447 +-----+ Access | +------+ | | +------+ | Access +-----+ 448 |CE | conn. | |VFI of| | Tunnel | |VFI of| | conn. | CE | 449 | dev |----------|VPN B |==================|VPN B |----------| dev | 450 | of | | +------+ | | +------+ | | of | 451 |VPN B| | | | | |VPN B| 452 +-----+ +----------+ +----------+ +-----+ 453 Figure 3.1 PE Usage of Separate Tunnels to Support VPNs 455 Carugi, McDysan et al Informational - Expires January 2005 9 457 Service requirements for Layer 3 PPVPNs July 2004 459 Figure 3.2 illustrates the case where a single hierarchical tunnel 460 is used between PE devices to support communication for VPNs. The 461 innermost encapsulating protocol header provides the means for the 462 PE to determine the VPN for which the packet is directed. 463 +----------+ +----------+ 464 +-----+ |PE device | |PE device | +-----+ 465 | CE | | | | | | CE | 466 | dev | Access | +------+ | | +------+ | Access | dev | 467 | of | conn. | |VFI of| | | |VFI of| | conn. | of | 468 |VPN A|----------|VPN A | | Hierarchical | |VPN A |----------|VPN A| 469 +-----+ | +------+\| Tunnel |/+------+ | +-----+ 470 | >==============< | 471 +-----+ Access | +------+/| |\+------+ | Access +-----+ 472 | CE | conn. | |VFI of| | | |VFI of| | conn. | CE | 473 | dev |----------|VPN B | | | |VPN B |----------| dev | 474 | of | | +------+ | | +------+ | | of | 475 |VPN B| | | | | |VPN B| 476 +-----+ +----------+ +----------+ +-----+ 477 Figure 3.2 PE Usage of Shared Hierarchical Tunnels to Support VPNs 479 3.6.2 CE-Based L3VPN Tunnel Endpoints and Functions 481 Figure 3.3 illustrates the CE-based L3 VPN reference model. In this 482 configuration, typically a single level of tunnel (e.g., IPsec) 483 terminates at pairs of CEs. Usually, a CE serves a single customer 484 site and therefore the forwarding and routing is physically separate 485 from all other customers. Furthermore, the PE is not aware of the 486 membership of specific CE devices to a particular VPN. Hence, the 487 VPN functions are implemented using provisioned configurations on 488 the CE devices and the shared PE and P network is used to only 489 provide the routing and forwarding that supports the tunnel 490 endpoints on between CE devices. The tunnel topology connecting the 491 CE devices may be a full or partial mesh, depending upon VPN 492 customer requirements and traffic patterns. 494 Carugi, McDysan et al Informational - Expires January 2005 10 496 Service requirements for Layer 3 PPVPNs July 2004 498 +---------+ +--------------------------------+ +---------+ 499 | | | | | | 500 | | | +------+ +------+ : +------+ 501 +------+ : | | | | | | : | CE | 502 | CE | : | | | P | | PE | : |device| 503 |device| : +------+ Tunnel |router| |device| : | of | 504 | of |=:================================================:=|VPN A| 505 |VPN A| : | | +------+ +------+ : +------+ 506 +------+ : | PE | | | : | 507 +------+ : |device| | | : | 508 | CE | : | | Tunnel +------+ : +------+ 509 |device|=:================================================:=| CE | 510 | of | : +------+ | PE | : |device| 511 |VPN B| : | | |device| : | of | 512 +------+ : | | +----------+ +----------+ | | : |VPN B| 513 | : | | | Customer | | Network | +------+ : +------+ 514 |Customer | | |management| |management| | | : | 515 |interface| | | function | | function | | |Customer | 516 | | | +----------+ +----------+ | |interface| 517 | | | | | | 518 +---------+ +--------------------------------+ +---------+ 519 | Access | |<-------- SP network(s) ------->| | Access | 520 | network | | | | network | 522 Figure 3.3 CE-based L3 VPN 524 3.7 Customer and Provider Network Management 525 Customer Network Management Function: A customer network management 526 function provides the means for a customer agent to query or 527 configure customer specific information, or receive alarms regarding 528 his or her VPN. Customer specific information includes data related 529 to contact, billing, site, access network, IP address, routing 530 protocol parameters, etc. It may use a combination of proprietary 531 network management system, SNMP manager, or directory service (e.g., 532 LDAP [RFC3377] [RFC2251]). 534 Provider Network Management Function: A provider network management 535 function provides many of the same capabilities as a customer 536 network management system across all customers. This would not 537 include customer confidential information, such as keying material. 538 The intent of giving the provider a view comparable to that of the 539 customer is to aid in troubleshooting and problem resolution. Such a 540 system also provides the means to query, configure, or receive 541 alarms regarding any infrastructure supporting the L3VPN service. It 542 may use a combination of proprietary network management system, SNMP 543 manager, or directory service (e.g., LDAP [RFC3377] [RFC2251]). 545 Carugi, McDysan et al Informational - Expires January 2005 11 547 Service requirements for Layer 3 PPVPNs July 2004 549 4 Service Requirements Common to Customers and Service Providers 551 Many of the requirements that apply to both the customer and the 552 provider and are of an otherwise general nature, or apply to both L2 553 and L3 VPNs, are described in [PPVPN-GR]. This section contains 554 requirements specific to L3 VPNs which are not covered in [PPVPN- 555 GR]. 557 4.1 Isolated Exchange of Data and Routing Information 558 A mechanism for isolating the distribution of reachability 559 information to only those sites associated with a VPN must be 560 provided. 562 L3VPN solutions shall define means that prevent routers in a VPN 563 from interaction with unauthorized entities and avoid introducing 564 undesired routing information that could corrupt the VPN 565 routing information base [VPN-CRIT]. 567 A means to constrain, or isolate, the distribution of addressed data 568 to only those VPN sites determined either by routing data and/or 569 configuration must be provided. 571 A single site shall be capable of being in multiple VPNs. The VPN 572 solution must ensure that traffic is exchanged only with those sites 573 that are in the same VPN. 575 The internal structure of a VPN should not be advertised nor 576 discoverable from outside that VPN. 578 Note that isolation of forwarded data and/or exchange of 579 reachability information to only those sites that are part of a VPN 580 may be viewed as a form of security, for example, [Y.1311.1],[MPLS 581 SEC]. 583 4.2 Addressing 585 IP addresses must be unique within the set of sites reachable from 586 the VPNs of which a particular site is a member. 588 A VPN solution must support IPv4 and IPv6 as both the encapsulating 589 and encapsulated protocol. 591 If a customer has private or non-unique IP addresses, then a VPN 592 service SHOULD be capable of translating such customer private or 593 non-unique IP addresses for communicating with IP systems having 594 public addresses. 596 4.3 Quality of Service 597 To the extent possible, L3 VPN QoS should be independent of the 598 access network technology. 600 Carugi, McDysan et al Informational - Expires January 2005 12 602 Service requirements for Layer 3 PPVPNs July 2004 604 4.3.1 QoS Standards 605 A non-goal of the L3 VPN WG effort (as chartered) is the development 606 of new protocols or extension of existing ones. With regards to QoS 607 support, a L3 VPN shall be able to support QoS in one or more of the 608 following already defined modes: 609 - Best Effort (mandatory support for all L3VPN types) 610 - Aggregate CE Interface Level QoS ("hose" level QoS) 611 - Site-to-site ("pipe" level QoS) 612 - Intserv (i.e., RSVP) signaled 613 - Diffserv marked 614 - Across packet-switched access networks 616 Note that all cases involving QoS may require that the CE and/or PE 617 perform shaping and/or policing. 619 L3VPN CEs should be capable of supporting integrated services 620 (Intserv) for certain customers in support of session applications, 621 such as switched voice or video. Intserv-capable CE devices shall 622 support the following Internet standards: 623 - Resource reSerVation Protocol (RSVP) [RFC 2205] 624 - Guaranteed Quality of Service providing a strict delay bound 625 [RFC 2212] 626 - Controlled Load Service providing performance equivalent to that 627 of an unloaded network [RFC 2211] 629 L3VPN CE and PE should be capable of supporting differentiated 630 service (Diffserv). . Diffserv-capable L3VPN CE and PE shall 631 support the following per hop behavior (PHB) [RFC 2475] types: 632 - Expedited Forwarding (EF) - the departure rate of an aggregate 633 class of traffic from a device that must equal or exceed a 634 configured rate [RFC 3246]. 635 - Assured Forwarding (AF) - a means for a provider Diffserv (DS) 636 domain to offer different levels of forwarding assurances for IP 637 packets received from a customer DS domain. Four AF classes are 638 defined, where each AF class implies allocation in each DS node of a 639 certain amount of forwarding resources (e.g., buffer space and 640 bandwidth) [RFC 2597]. 642 A CE or PE device supporting a L3 VPN service may classify a packet 643 for a particular Intserv or Diffserv service based on upon one or 644 more of the following IP header fields: protocol ID, source port 645 number, destination port number, destination address, or source 646 address. 648 For a specifiable set of Internet traffic, L3 VPN devices should 649 support Random Early Detection (RED) to provide graceful degradation 650 in the event of network congestion. 652 Carugi, McDysan et al Informational - Expires January 2005 13 654 Service requirements for Layer 3 PPVPNs July 2004 656 4.3.2 Service Models 657 A service provider must be able to offer QoS service to a customer 658 for at least the following generic service types: managed access VPN 659 service or edge-to-edge QoS VPN service [PPVPN-GR]. More detail 660 specific to L3 VPNs is provided below. 662 A managed access L3 VPN service provides QoS on the access 663 connection between the CE and the PE. For example, diffserv would be 664 enabled only on the CE router and the customer-facing ports of the 665 PE router. Note that this service would not require Diffserv 666 implementation in the SP backbone. The SP may use policing for 667 inbound traffic at the PE. The CE may perform shaping for outbound 668 traffic. Another example of a managed access L3 VPN service is where 669 the SP performs the packet classification and diffserv marking. An 670 SP may provide several packet classification profiles that customers 671 may select, or may offer custom profiles based upon customer 672 specific requirements. In general, more complex QoS policies should 673 be left to the customer for implementation. 675 An edge-to-edge QoS VPN service provides QoS from edge device to 676 edge device. The edge device may be either PE or CE depending upon 677 the service demarcation point between the provider and the customer. 678 Such a service may be provided across one or more provider 679 backbones. The CE requirements for this service model are the same 680 as the managed access VPN service. However, in this service QoS is 681 provided from one edge of the SP network(s) to the other edge. 683 4.4 Service Level Specification and Agreements 685 A generic discussion of SLAs is provided in [PPVPN-GR]. 686 Additionally, SLS measurements for quality based on the DiffServ 687 scheme SHOULD be based upon the following classification: 689 . A Point-to-Point SLS [Y.1311.1], sometimes also referred to as 690 the "Pipe" model, defines traffic parameters in conjunction 691 with the QoS objectives for traffic exchanged between a pair 692 of VPN sites (i.e., points). A Point-to-Point SLS is analogous 693 to the SLS typically supported over point-to-point Frame Relay 694 or ATM PVCs or an edge-to-edge MPLS tunnel. The set of SLS 695 specifications to all other reachable VPN sites would define 696 the overall Point-to-Point SLS for a specific site. 698 . A Point-to-Cloud SLS [Y.1311.1], sometimes also referred as 699 the "Hose" model, defines traffic parameters in conjunction 700 with the QoS objectives for traffic exchanged between a CE and 701 a PE for traffic destined to a set (either all or a subset) of 702 other sites in the VPN (i.e., the cloud), as applicable. In 703 other words, a point-to-cloud SLS defines compliance in terms 704 of all packets transmitted from a given VPN site toward the SP 705 network on an aggregate basis (i.e., regardless of the 706 destination VPN site of each packet). 708 Carugi, McDysan et al Informational - Expires January 2005 14 710 Service requirements for Layer 3 PPVPNs July 2004 712 . A Cloud-to-Point SLS (a case not covered by this SLS is where 713 flows originating from multiple sources may congest the 714 interface from the network toward a specific site). 716 Traffic parameters and actions SHOULD be defined for packets to and 717 from the demarcation between the service provider and the site. For 718 example, policing may be defined on ingress and shaping on egress. 720 4.5 Management 721 An SP and its customers MUST be able to manage the capabilities and 722 characteristics of their VPN services. To the extent possible, 723 automated operations and interoperability with standard management 724 platforms SHOULD be supported. 726 The ITU-T Telecommunications Management Network (TMN) model has the 727 following generic requirements structure: 728 O Engineer, deploy and manage the switching, routing and 729 transmission resources supporting the service, from a network 730 perspective (network element management); 731 O Manage the VPN networks deployed over these resources (network 732 management); 733 o Manage the VPN service (service management); 734 o Manage the VPN business, mainly provisioning administrative and 735 accounting information related to the VPN service customers 736 (business management). 738 Service management should include the TMN 'FCAPS' functionalities, 739 as follows: Fault, Configuration, Accounting, Provisioning, and 740 Security, as detailed in section 7. 742 4.6 Interworking 743 Interworking scenarios among different solutions providing L3VPN 744 services is highly desirable. See the L3VPN framework document for 745 more details on interworking scenarios [L3VPN-FR]. Interworking 746 SHOULD be supported in a scalable manner. 748 Interworking scenarios MUST consider at least traffic and routing 749 isolation, security, QoS, access, and management aspects. This 750 requirement is essential in the case of network migration, to ensure 751 service continuity among sites belonging to different portions of 752 the network. 754 5 Customer Requirements 755 This section captures additional requirements from a customer 756 perspective. 758 5.1 VPN Membership (Intranet/Extranet) 759 When an extranet is formed, a customer agent from each of the 760 organizations first approves addition of a site to an extranet VPN 761 as a business decision between the parties involved. The solution 762 SHOULD provide a means such that these organizations can control 764 Carugi, McDysan et al Informational - Expires January 2005 15 766 Service requirements for Layer 3 PPVPNs July 2004 768 extranet communication involving the L3VPN exchange of traffic and 769 routing information. 771 5.2 Service Provider Independence 772 Customers MAY require VPN service that spans multiple administrative 773 domains or service provider networks. Therefore, a VPN service MUST 774 be able to span multiple AS and SP networks, but still act and 775 appear as a single, homogenous VPN from a customer point of view. 777 A customer might also start with a VPN provided in a single AS with 778 a certain SLA but then ask for an expansion of the service spanning 779 multiple ASs/SPs. In this case, as well as for all kinds of multi- 780 AS/SP VPNs, VPN service SHOULD be able to deliver the same SLA to 781 all sites in a VPN regardless of the AS/SP to which it homes. 783 5.3 Addressing 784 A customer requires support from a L3 VPN for the following 785 addressing IP assignment schemes: 786 o customer assigned, non-unique, or RFC 1918 private addresses 787 o globally unique addresses obtained by the customer 788 o globally unique addresses statically assigned by the L3VPN 789 service provider 790 o on-demand, dynamically assigned IP addresses (e.g., DHCP), 791 irrespective of whether the access is temporary (e.g., remote) or 792 permanent (i.e., dedicated) 794 In the case of combined L3 VPN service with non-unique or private 795 addresses and Internet access, mechanisms that permit the exchange 796 of traffic between the customer's address space and the global 797 unique Internet address space MAY be supported. For example, NAT is 798 employed by many customers and some service providers today to meet 799 this need. A preferred solution would be to assign unique addresses, 800 either IPv4 or IPv6; however, some customers do not want to renumber 801 their networks. 803 5.4 Routing Protocol Support 804 There SHOULD be no restriction on the routing protocols used between 805 CE and PE routers, or between CE routers. At least the following 806 protocols MUST be supported: static routing, IGP protocols, such as 807 RIP, OSPF, IS-IS, and BGP [L3VPN-FR]. 809 5.5 Quality of Service and Traffic Parameters 810 QoS is expected to be an important aspect of a L3VPN service for 811 some customers. QoS requirements cover scenarios involving an 812 intranet, an extranet, as well as shared access between a VPN site 813 and the Internet. 815 5.5.1 Application Level QoS Objectives 816 A customer is concerned primarily that the L3VPN service provide his 817 or her applications with the QoS and level of traffic such that the 818 applications perform acceptably. Voice and interactive video, and 819 multimedia applications are expected to require the most stringent 821 Carugi, McDysan et al Informational - Expires January 2005 16 823 Service requirements for Layer 3 PPVPNs July 2004 825 QoS. These real-time applications are sensitive to delay, delay 826 variation, loss, availability and/or reliability. Another set of 827 applications, including some multimedia and interactive video 828 applications, high-performance web browsing and file transfer 829 intensive applications, requires near real time performance. 830 Finally, best effort applications are not sensitive to degradation, 831 that is are elastic and can adapt to conditions of degraded 832 performance. 834 The selection of appropriate QoS and service type to meet specific 835 application requirements is particularly important to deal with 836 periods of congestion in a SP network. Sensitive applications will 837 likely select per-flow Integrated service (Intserv) with precise SLA 838 guarantees measured on a per flow basis. On the other hand, non- 839 sensitive applications will likely rely on a Diffserv class-based 840 QoS. 842 The fundamental customer application requirement is that a L3VPN 843 solution MUST support both the Intserv QoS model for selected 844 individual flows, and Diffserv for aggregated flows. 846 A customer application SHOULD experience consistent QoS independent 847 of the access network technology used at different sites connected 848 to the same VPN. 850 5.5.2 DSCP Transparency 851 The Diffserv Code Point (DSCP) set by a user as received by the 852 ingress CE SHOULD be capable of being relayed transparently to the 853 egress CE [see section 2.6.2 of RFC 3270 and Y.1311.1]. Although RFC 854 2475 states that interior or boundary nodes within a DS domain can 855 change the DSCP, customer VPNs MAY have other requirements, such as: 856 o Applications that use the DSCP in a manner differently than the 857 DSCP solution supported by the SP network(s); 858 o Customers using more DSCPs within their sites than the SP 859 network(s) supports; 860 o Support for a carrier's carrier service where one SP is the 861 customer of another L3VPN SP. Such an SP should be able to resell 862 VPN service to his or her VPN customers independently of the DSCP 863 mapping solution supported by the carrier's carrier SP. 865 Note that support for DSCP transparency has no implication on the 866 QoS or SLA requirements. If an SP supports DSCP transparency, then 867 that SP needs to only carry the DSCP values across its domain, but 868 MAY map the received DSCP to some other value for QoS support across 869 its domain. 871 5.6 Service Level Specification/Agreement 872 Most customers simply want their applications to perform well. An 873 SLA is a vehicle for customer recourse in the event that SP(s) do 874 not perform or manage a VPN service well in a measurable sense. 875 Therefore, when purchasing service under an SLA, a customer agent 877 Carugi, McDysan et al Informational - Expires January 2005 17 879 Service requirements for Layer 3 PPVPNs July 2004 881 MUST have access to the measures from the SP(s) that support the 882 SLA. 884 5.7 Customer Management of a VPN 885 A customer MUST have a means to view the topology, operational 886 state, order status, and other parameters associated with his or her 887 VPN. 889 Most aspects of management information about CE devices and customer 890 attributes of a L3VPN manageable by an SP SHOULD be capable of being 891 configured and maintained by an authenticated, authorized customer 892 agent. However, some aspects, such as encryption keys, SHALL NOT be 893 readable nor writable by management systems. 895 A customer agent SHOULD be able to make dynamic requests for changes 896 to traffic parameters. A customer SHOULD be able to receive real- 897 time response from the SP network in response to these requests. 898 One example of such service is a "Dynamic Bandwidth management" 899 capability, that enables real-time response to customer requests for 900 changes of allocated bandwidth allocated to his or her VPN 901 [Y.1311.1]. 903 A customer who may not be able to afford the resources to manage his 904 own sites SHOULD be able to outsource the management of the entire 905 VPN to the SP(s) supporting the VPN network. 907 5.8 Isolation 908 These features include traffic and routing information exchange 909 isolation, similar to that obtained in VPNs based on Layer 1 and 910 Layer 2 (e.g., private lines, FR, or ATM) [MPLS SEC]. 912 5.9 Security 913 The suite of L3VPN solutions SHOULD support a range of security 914 related features. Higher levels of security services, like edge-to- 915 edge encryption, authentication, or replay attack should be 916 supported. More details on customer requirements for security are 917 described in [VPNSEC]. 919 Security in a L3VPN service SHOULD be as transparent as possible to 920 the customer, with the obvious exception of support for remote or 921 temporary user access, as detailed in section 5.11.2. 923 L3VPN customers MUST be able to deploy their own internal security 924 mechanisms in addition to those deployed by the SP, in order to 925 secure specific applications or traffic at a granularity finer than 926 a site-to-site basis. 928 If a customer requires QoS support in a L3 VPN, then this request 929 MUST be communicated to the SP either using unencrypted fields or 930 else via an agreed security association. For example, applications 931 could send RSVP messages in support of Intserv either in the clear 932 or encrypted using a key negotiated with the SP. Another case is 934 Carugi, McDysan et al Informational - Expires January 2005 18 936 Service requirements for Layer 3 PPVPNs July 2004 938 where applications using an IPsec tunnel could copy the DSCP from 939 the encrypted IP header to the header of the tunnel's IP header. 941 5.10 Migration Impact 942 Often, customers are migrating from an already deployed private 943 network toward one or more L3 VPN solutions. A typical private 944 network scenario is CE routers connected via real or virtual 945 circuits. Ideally, minimal incremental cost SHOULD result during the 946 migration period. Furthermore, if necessary, any disruption of 947 service SHOULD also be minimized. 949 A range of scenarios of customer migration MUST be supported. Full 950 migration of all sites MUST be supported. Support for cases of 951 partial migration is highly desirable [Y.1311.1], that is, legacy 952 private network sites that belong to the L3VPN service SHOULD still 953 have L3 reachability to the sites that migrate to the L3VPN service. 955 5.11 Network Access 956 Every L3 packet exchanged between the customer and the SP over the 957 access connection MUST appear as it would on a private network 958 providing an equivalent service to that offered by the L3VPN. 960 5.11.1 Physical/Link Layer Technology 961 L3VPNs SHOULD support a broad range of physical and link layer 962 access technologies, such as PSTN, ISDN, xDSL, cable modem, leased 963 line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local 964 loop, mobile radio access, etc. The capacity and QoS achievable may 965 be dependent on the specific access technology in use. 967 5.11.2 Temporary Access 968 The VPN service offering SHOULD allow both permanent and temporary 969 access to one or more L3VPNs for authenticated users across a broad 970 range of access technologies. Support for remote or temporary VPN 971 access SHOULD include ISDN, PSTN dial-in, xDSL or access via another 972 SP network. The customer SHOULD be able to choose from alternatives 973 for authentication of temporary access users. Choices for access 974 authentication are: SP-provided, third-party, or customer-provided 975 authentication. 977 A significant number of VPN users may not be permanently attached to 978 one VPN site : in order to limit access to a VPN to only authorized 979 users, it is first necessary to authenticate them. Authentication 980 SHALL apply as configured by the customer agent and/or SP where a 981 specific user may be part of one or more VPNs. The authentication 982 function SHOULD be used to automatically invoke all actions 983 necessary to join a user to the VPN. 985 A user SHOULD be able to access a L3VPN via a network having generic 986 Internet access. 988 Carugi, McDysan et al Informational - Expires January 2005 19 990 Service requirements for Layer 3 PPVPNs July 2004 992 Mobile users may move within a L3VPN site. Mobile users may also 993 have temporary connections to different L3VPN site within the same 994 VPN. Authentication SHOULD be provided for both of these cases. 996 5.11.3 Sharing of the Access Network 997 In a PE-based L3VPN, if the site shares the access network with 998 other traffic (e.g., access to the Internet), then data security in 999 the access network is the responsibility of the L3VPN customer. 1001 5.11.4 Access Connectivity 1002 Various types of physical connectivity scenarios MUST be supported, 1003 such as multi-homed sites, backdoor links between customer sites, 1004 devices homed to two or more SP networks. L3VPN solutions SHOULD 1005 support at least the types of physical or link-layer connectivity 1006 arrangements shown in Figure 5.1. Support for other physical 1007 connectivity scenarios with arbitrary topology is desirable. 1009 Access arrangements with multiple physical or logical paths from a 1010 CE to other CEs and PEs MUST support redundancy, and SHOULD support 1011 load balancing. Resiliency uses redundancy to provide connectivity 1012 between a CE site and other CE sites, and optionally, other 1013 services. Load balancing provides a means to perform traffic 1014 engineering such that capacity on redundant links is used to achieve 1015 improved performance during periods when the redundant component(s) 1016 are available. 1018 For multi-homing to a single SP, load balancing capability SHOULD be 1019 supported by the PE across the CE to PE links. For example, in case 1020 (a), load balancing SHOULD be provided by the two PEs over the two 1021 links connecting to the single CE. In case (c), load balancing 1022 SHOULD be provided by the two PEs over the two links connecting to 1023 the two CEs. 1025 In addition, the load balancing parameters (e.g., the ratio of 1026 traffic on the multiple load-balanced links, or the preferred link) 1027 SHOULD be provisionable based on customer's requirements. The load 1028 balancing capability may also be used to achieve resiliency in the 1029 event of access connectivity failures. For example, in cases (b) a 1030 CE may connect to two different SPs via diverse access networks. 1031 Resiliency MAY be further enhanced as shown in case (d), where CEs 1032 connected via a "back door" connection connect to different SPs. 1033 Furthermore, arbitrary combinations of the above methods, with a few 1034 examples shown in cases (e) and (f) should be supportable by any 1035 L3VPN approach. 1037 For multi-homing to multiple SPs, load balancing capability MAY also 1038 be supported by the PEs in the different SPs (clearly, this is a 1039 more complex type of load balancing to realize, and requires policy 1040 and service agreements between the SPs to interoperate). 1042 Carugi, McDysan et al Informational - Expires January 2005 20 1044 Service requirements for Layer 3 PPVPNs July 2004 1046 +---------------- +--------------- 1047 | | 1048 +------+ +------+ 1049 +---------| PE | +---------| PE | 1050 | |router| | |router| SP network 1051 | +------+ | +------+ 1052 +------+ | +------+ | 1053 | CE | | | CE | +--------------- 1054 |device| | SP network |device| +--------------- 1055 +------+ | +------+ | 1056 | +------+ | +------+ 1057 | | PE | | | PE | 1058 +---------|router| +---------|router| SP network 1059 +------+ +------+ 1060 | | 1061 +---------------- +--------------- 1062 (a) (b) 1063 +---------------- +--------------- 1064 | | 1065 +------+ +------+ +------+ +------+ 1066 | CE |-----| PE | | CE |-----| PE | 1067 |device| |router| |device| |router| SP network 1068 +------+ +------+ +------+ +------+ 1069 | | | | 1070 | Backdoor | | Backdoor +--------------- 1071 | link | SP network | link +--------------- 1072 | | | | 1073 +------+ +------+ +------+ +------+ 1074 | CE | | PE | | CE | | PE | 1075 |device|-----|router| |device|-----|router| SP network 1076 +------+ +------+ +------+ +------+ 1077 | | 1078 +---------------- +--------------- 1079 (c) (d) 1080 +---------------- +--------------- 1081 | | 1082 +------+ +------+ +------+ +------+ 1083 | CE |-----| PE | | CE |-----| PE | 1084 |device| |router| |device| |router| SP network 1085 +------+\ +------+ +------+\ +------+ 1086 | \ | | \ | 1087 |Back \ | |Back \ +--------------- 1088 |door \ | SP network |door \ +--------------- 1089 |link \ | |link \ | 1090 +------+ +------+ +------+ +------+ 1091 | CE | | PE | | CE | | PE | 1092 |device|-----|router| |device|-----|router| SP network 1093 +------+ +------+ +------+ +------+ 1094 | | 1095 +---------------- +--------------- 1096 (e) (f) 1097 Figure 5.1 Representative types of access arrangements. 1099 Carugi, McDysan et al Informational - Expires January 2005 21 1101 Service requirements for Layer 3 PPVPNs July 2004 1103 5.12 Service Access 1104 Customers MAY also require access to other services, as described in 1105 this section. 1107 5.12.1 Internet Access 1108 Customers SHOULD be able to have L3 VPN and Internet access across 1109 the same access network for one or more of the customer's sites. 1111 Customers SHOULD be able to direct Internet traffic from the set of 1112 sites in the L3VPN to one or more customer sites that have 1113 firewalls, other security-oriented devices, and/or NAT that process 1114 all traffic between the Internet and the customer's VPN. 1116 L3 VPN Customers SHOULD be able to receive traffic from the Internet 1117 addressed to a publicly accessible resource that is not part of the 1118 VPN, such as an enterprise's public web server. 1120 As stated in section 5.3, if a customer L3 VPN employs private or 1121 non-unique IP addresses, then network address translation (NAT) or a 1122 similar mechanism MUST be provided either by the customer or the SP 1123 in order to be able to exchange traffic with devices outside the 1124 customer's L3 VPN. 1126 5.12.2 Hosting, Application Service Provider 1127 A customer SHOULD be able to access hosting, other application 1128 services, or other Application Service Providers (ASP) over a L3 1129 L3VPN service. This MAY require that an ASP participates in one or 1130 more VPNs with the customers that use such a service. 1132 5.12.3 Other Services 1133 In conjunction with a VPN service, a customer MAY also wish to have 1134 access to other services, such as: DNS, FTP, HTTP, NNTP, SMTP, LDAP, 1135 VoIP, NAT, LDAP, Videoconferencing, Application sharing, E-business, 1136 Streaming, E-commerce, Directory, Firewall, etc. The resources that 1137 implement these services could be physically dedicated to each VPN. 1138 If the resources are logically shared, then they MUST have access 1139 separated and isolated between VPNs in a manner consistent with the 1140 L3VPN solution to meet this requirement. 1142 5.13 Hybrid VPN Service Scenarios 1143 Intranet or extranet customers have a number of reasons for wanting 1144 hybrid networks that involve more than one VPN solution type. These 1145 include migration, mergers, extranet customers with different VPN 1146 types, the need for different capabilities between different sets of 1147 sites, temporary access, different availability of VPN solutions as 1148 provided by different service providers. 1150 The framework and solution approaches SHOULD include provisions for 1151 interworking, interconnection, and/or reachability between different 1153 Carugi, McDysan et al Informational - Expires January 2005 22 1155 Service requirements for Layer 3 PPVPNs July 2004 1157 L3VPN solutions in such a way that does not overly complicate 1158 provisioning, management, scalability, or performance. 1160 6 Service Provider Network Requirements 1161 This section describes requirements from a service provider 1162 perspective. 1164 6.1 Scalability 1165 [PPVPN-GR} lists projections regarding L3VPN sizing and scalability 1166 requirements and metrics related to specific solutions. 1168 6.2 Addressing 1169 As described in section 4.2, SPs MUST have support for public and 1170 private IP addresses, IPv4 and IPv6, for both unicast and multicast. 1171 In order to support this range of addressing schemes, SPs require 1172 the following support from L3VPN solutions. 1174 A L3VPN solution MUST be able to assign blocks of addresses from its 1175 own public IP address space to L3VPN customer sites in such a way 1176 that advertisement of routes to other SPs and other sites aggregates 1177 efficiently. 1179 A L3VPN solution MUST be able to use address assignments made by a 1180 customer. These customer assigned addresses may be public, or 1181 private. 1183 In the case where private IP addresses are used, a L3VPN solution 1184 MUST provide a means for an SP to translate such addresses to public 1185 IP addresses for communication with other VPNs using overlapping 1186 addresses, or the Internet. 1188 6.3 Identifiers 1189 A number of identifiers MAY be necessary for SP use in management, 1190 control, and routing protocols. Requirements for at least the 1191 following identifiers are known. 1193 An SP domain MUST be uniquely identified at least within the set of 1194 all interconnected SP networks when supporting a VPN that spans 1195 multiple SPs. Ideally, this identifier should be globally unique 1196 (e.g., an AS number). 1198 An identifier for each VPN SHOULD be unique, at least within each 1199 SP's network. Ideally, the VPN identifier SHOULD be globally unique 1200 to support the case where a VPN spans multiple SPs (e.g., [RFC 1201 2685]). 1203 A CE device SHOULD have a unique identifier, at least within each 1204 SP's network. 1206 A PE device SHOULD have a unique identifier, at least within each 1207 SP's network. 1209 Carugi, McDysan et al Informational - Expires January 2005 23 1211 Service requirements for Layer 3 PPVPNs July 2004 1213 The identifier of a device interconnecting SP networks MUST be 1214 unique within the set of aforementioned networks. 1216 Each site interface SHOULD have a unique identifier, at least within 1217 each PE router supporting such an interface. 1219 Each tunnel SHOULD have a unique identifier, at least within each 1220 router supporting the tunnel. 1222 6.4 Discovering VPN Related Information 1223 Configuration of CE and PE devices is a significant task for a 1224 service provider. Solutions SHOULD strive to contain methods that 1225 dynamically allow VPN information to be discovered (or learned) by 1226 the PE and/or CE to reduce configuration complexity. The following 1227 specific requirements apply to intra and inter-provider VPNs [VPN 1228 DISC]. 1230 Every device involved in a VPN SHALL be able to identify and 1231 authenticate itself to other devices in the VPN. After learning the 1232 VPN membership, the devices SHOULD be able to securely exchange 1233 configuration information. The VPN information MUST include at least 1234 the IP address of the PE and may be extensible to provide additional 1235 information. 1237 Each device in a VPN SHOULD be able to determine which other devices 1238 belong to the same VPN. Such a membership discovery scheme MUST 1239 prevent unauthorized access and allow authentication of the source. 1241 Distribution of VPN information SHOULD be limited to those devices 1242 involved in that VPN. 1244 In the case of a PE-based VPN, a solution SHOULD support the means 1245 for attached CEs to authenticate each other and verify that the SP's 1246 VPN network is correctly configured. 1248 The mechanism SHOULD respond to VPN membership changes in a timely 1249 manner. A "timely manner" is no longer than the provisioning 1250 timeframe, typically on the order of minutes, and could be as short 1251 as the timeframe required for "rerouting," typically on the order of 1252 seconds. 1254 Dynamically creating, changing, and managing multiple VPN 1255 assignments to sites and/or customers is another aspect of 1256 membership that MUST be addressed in a L3 VPN solution. 1258 6.5 SLA and SLS Support 1259 Typically, a Service Provider offering a L3VPN service commits to 1260 specific Service Level Specifications (SLS) as part of a contract 1261 with the customer, as described in section 4.4 and [PPVPN-GR]. Such 1262 a Service Level Agreement (SLA) implies SP requirements for 1263 measuring Specific Service Level Specifications (SLS) for quality, 1264 availability, response time, and configuration intervals. 1266 Carugi, McDysan et al Informational - Expires January 2005 24 1268 Service requirements for Layer 3 PPVPNs July 2004 1270 6.6 Quality of Service (QoS) and Traffic Engineering 1271 A significant aspect of a L3VPN is support for QoS. Since an SP has 1272 control over the provisioning of resources and configuration of 1273 parameters in at least the PE and P devices, and in some cases, the 1274 CE device as well, the onus is on the SP to provide either managed 1275 QoS access service, or edge-to-edge QoS service, as defined in 1276 section 4.3.2. 1278 Each L3VPN approach MUST describe the traffic engineering techniques 1279 available for a SP to meet the QoS objectives. These descriptions of 1280 traffic engineering techniques SHOULD quantify scalability and 1281 achievable efficiency. Traffic engineering support MAY be on an 1282 aggregate or per-VPN basis. 1284 QoS policies MUST not be impacted by security mechanisms. For 1285 example, Diffserv policies MUST not be impacted by the use of IPSec 1286 tunnels, using the mechanisms explained in RFC 2983. 1288 As stated in RFC 2475, a mapping function from customer provided 1289 Diffserv marking to marking used in a SP network should be provided 1290 for L3 VPN services. 1292 In the case where a customer requires DSCP transparency, as 1293 described in section 5.5.2, a L3 VPN service MUST deliver the same 1294 value of DSCP field in the IP header received from the customer to 1295 the egress demarcation of the destination. 1297 6.7 Routing 1298 The distribution of reachability and routing policy SHOULD be 1299 constrained to the sites that are members of the VPN. 1301 Optionally, the exchange of such information MAY use some form of 1302 authentication (e.g., MD5). 1304 Functions to isolate the SP network and customer VPNs from anomalous 1305 routing behavior from a specific set of customer sites SHOULD be 1306 provided. Examples of such functions are: controls for route flap 1307 dampening, filters that accept only prefixes configured for a 1308 specific CE, a maximum number of routes accepted for each CE, or a 1309 maximum rate at which route updates can be received from a CE. 1311 When VPN customers use overlapping, non-unique IP addresses, the 1312 solution MUST define a means to distinguish between such overlapping 1313 addresses on a per-VPN basis. 1315 Furthermore, the solution SHOULD provide an option that either 1316 allows, or prevents advertisement of VPN routes to the Internet. 1318 Ideally, the choice of a SP's IGP SHOULD not depend on the routing 1319 protocol(s) used between PE and CE routers in a PE-based VPN. 1321 Carugi, McDysan et al Informational - Expires January 2005 25 1323 Service requirements for Layer 3 PPVPNs July 2004 1325 Furthermore, it is desirable that an SP SHOULD have a choice with 1326 regards to the IGP routing protocol. 1328 The additional routing burden that an SP must carry should be 1329 articulated in each specific L3 VPN solution. 1331 6.8 Isolation of Traffic and Routing 1332 The internal structure of a L3VPN network SHOULD not be visible to 1333 outside networks (i.e., the Internet or any connected VPN). 1335 From a high level SP perspective, a PE-based L3VPN MUST isolate the 1336 exchange of traffic and routing information to only those sites that 1337 are authenticated and authorized members of a VPN. 1339 In a CE-based VPN, the tunnels that connect the sites effectively 1340 meet this isolation requirement if both traffic and routing 1341 information flow over the tunnels. 1343 A L3VPN solution SHOULD provide a means for meeting L3VPN QoS SLA 1344 requirements that isolates VPN traffic from the affects of traffic 1345 offered by non-VPN customers. Also, L3VPN solutions SHOULD provide a 1346 means to isolate the effects that traffic congestion produced by 1347 sites as part of one VPN can have on another VPN. 1349 6.9 Security 1350 This section contains requirements related to securing customer 1351 flows, providing authentication services for temporary, remote or 1352 mobile users, and the need to protect service provider resources 1353 involved in supporting a L3VPN. More detailed security requirements 1354 are provided in [VPNSEC]. 1356 6.9.1 Support for Securing Customer Flows 1357 In order to meet the general requirement for providing a range of 1358 security options to a customer, each L3VPN solution MUST clearly 1359 spell out the configuration options that can work together and how 1360 the can do so. 1362 When a VPN solution operates over a part of the Internet, it should 1363 support a configurable option to support one or more of the 1364 following standard IPsec methods for securing a flow for a specified 1365 subset of a customer's VPN traffic: 1366 o confidentiality, so that only authorized devices can decrypt it, 1367 o integrity, to ensure that the data has not been altered, 1368 o authentication, to ensure that the sender is indeed who he or she 1369 claims to be, 1370 o replay attack prevention. 1372 The above functions SHOULD be capable of being applied to "data 1373 traffic" of the customer, which includes the traffic exchanged 1374 between sites, between temporary users and sites and even between 1375 temporary users. It SHOULD also be possible to apply these functions 1376 to "control traffic", such as routing protocol exchanges, that are 1378 Carugi, McDysan et al Informational - Expires January 2005 26 1380 Service requirements for Layer 3 PPVPNs July 2004 1382 not necessarily perceived by the customer but nevertheless essential 1383 to maintain his or her VPN. 1385 Furthermore, such security methods MUST be configurable between 1386 different end points, such as CE-CE, PE-PE, and CE-PE. It is also 1387 desirable to configure security on a per-route or per-VPN basis [VPN 1388 SEC]. 1390 A VPN solution MAY support one or more encryption schemes, including 1391 AES, 3DES. Encryption, decryption, and key management SHOULD be 1392 included in profiles as part of the security management system. 1394 6.9.2 Authentication Services 1395 A service provider MUST provide authentication services in support 1396 of temporary user access requirements, as described in section 1397 5.11.2. 1399 Furthermore, traffic exchanged within the scope of VPN MAY involve 1400 several categories of equipment that must cooperate together to 1401 provide the service [Y.1311.1]. These network elements can be CE, 1402 PE, firewalls, backbone routers, servers, management stations, etc. 1403 These network elements learn about each others identity, either via 1404 manual configuration or via discovery protocols, as described in 1405 section 6.4. When network elements must cooperate, these network 1406 elements SHALL authenticate peers before providing the requested 1407 service. This authentication function MAY also be used to control 1408 access to network resources. 1410 The peer identification and authentication function described above 1411 applies only to network elements participating in the VPN. Examples 1412 include: 1413 - traffic between a CE and a PE, 1414 - traffic between CEs belonging to the same VPN, 1415 - CE or PE routers dealing with route announcements for a VPN, 1416 - policy decision point [RFC 3198] and a network element, 1417 - management station and an SNMP agent. 1419 Each L3VPN solution SHOULD describe for a peer authentication 1420 function: where it is necessary, how it shall be implemented, how 1421 secure it must be, and the way to deploy and maintain identification 1422 and authentication information necessary to operate the service. 1424 6.9.3 Resource Protection 1425 Recall from the definitions in section 3.3, that a site can be part 1426 of an intranet with sites from the only same organization, part of 1427 an extranet involving sites from other organizations, have access to 1428 the Internet, or any combination of these scopes of communication. 1429 Within these contexts, a site might be subject to various attacks 1430 coming from different sources. Potential sources of attack include: 1431 - users connected to the supporting public IP backbone, 1432 - users from the Internet, 1434 Carugi, McDysan et al Informational - Expires January 2005 27 1436 Service requirements for Layer 3 PPVPNs July 2004 1438 - users from temporary sites belonging to the intranet and/or 1439 extranet VPN that the site is part of. 1441 Security threats and risks that a site may encounter include the 1442 following: 1443 - denial of service, for example mail spamming, access connection 1444 congestion, TCP SYN attacks, ping attacks, etc. 1445 - intrusion attempts, which may eventually lead to denial of 1446 service (e.g. a Trojan horse attack). 1448 Additional threat scenarios are defined in [VPNSEC]. A L3 VPN 1449 solution MUST state how it addresses each potential threat scenario. 1451 The devices in the L3VPN network must provide some means of 1452 reporting intrusion attempts to the service provider resources. 1454 6.10 Inter-AS (SP)VPNs 1455 The scenario for VPNs spanning multiple Autonomous Systems (AS) or 1456 Service Providers (SP) requires standard solutions. The scenario 1457 where multiple ASs are involved is the most general case, and is 1458 therefore the one described here. The scenarios of concern are the 1459 CE-based and PE-based L3 VPNs defined in section 3. 1461 In each scenario, all applicable SP requirements, such as traffic 1462 and routing isolation, SLA's, management, security, provisioning, 1463 etc. MUST be preserved across adjacent ASs. The solutions MUST 1464 describe the inter-SP network interface, encapsulation method(s), 1465 routing protocol(s), and all applicable parameters [VPN IW]. 1467 An essential pre-condition for an inter-AS VPN is an agreement 1468 between the ASs involved that spells out at least trust, economic, 1469 and management responsibilities. 1471 The overall scalability of the VPN service MUST allow the L3VPN 1472 service to be offered across potentially hundreds of SPs, with the 1473 overall scaling parameters per SP given in [PPVPN-GR]. 1475 6.10.1 Routing Protocols 1476 If the link between ASs is not trusted, routing protocols running 1477 between those ASs MUST support some form of authentication. For 1478 example, the TCP option for carrying an MD5 digest may be used to 1479 enhance security for BGP [RFC2385]. 1481 BGP MUST be supported as the standard inter-AS routing protocol to 1482 control the path taken by L3VPN traffic. 1484 6.10.2 Management 1485 The general requirements for managing a single AS apply to a 1486 concatenation of ASs. A minimum subset of such capabilities is the 1487 following: 1488 - Diagnostic tools (e.g., ping, traceroute) 1489 - Secured access to one AS management system by another 1491 Carugi, McDysan et al Informational - Expires January 2005 28 1493 Service requirements for Layer 3 PPVPNs July 2004 1495 - Configuration request and status query tools 1496 - Fault notification and trouble tracking tools 1498 6.10.3 Bandwidth and QoS Brokering 1499 When a VPN spans multiple ASs, there is a desire for a brokering 1500 mechanism that requests certain SLA parameters, such as bandwidth 1501 and QoS, from the other domains and/or networks involved in 1502 transferring traffic to various sites. Although bandwidth and QoS 1503 brokering across multiple ASs is not common in today's networks, 1504 these may be desirable in order to maintain SLAs in inter-AS VPNs. 1505 This section describes requirements for features that would 1506 facilitate these mechanisms. The objective is that a solution SHOULD 1507 be able to determine whether a set of ASs can establish and 1508 guarantee uniform QoS in support of a L3VPN. 1510 The brokering mechanism can be a manual one, for example, where one 1511 provider requests from another provider a specific set of bandwidth 1512 and QoS parameters for traffic going to and from a specific set of 1513 sites. The mechanism could also be an automated one where a device 1514 dynamically requests and receives certain bandwidth and SLA/QoS 1515 parameters. For instance, in the case of a L3 VPN over MPLS, a PE 1516 may negotiate the label for different traffic classes to reach a PE 1517 residing in a neighboring AS. Or, it might be a combination of both. 1518 For additional detailed requirements on the automated approach, see 1519 [TE-INTERAS]. 1521 It is not desirable to perform brokering on a per VPN basis since 1522 such an approach would not scale. A solution MUST provide some means 1523 of aggregating QoS and bandwidth brokering requests between ASs. One 1524 method could be for SP's to make an agreement specifying the maximum 1525 amount of bandwidth for specific QoS parameters for all VPN 1526 customers using the SP network. Alternatively, such aggregation 1527 might be on a per hierarchical tunnel basis between PE routers in 1528 different ASs supporting a L3 VPN service [TE-INTERAS]. 1530 6.10.4 Security Considerations 1531 If a tunnel traverses multiple SP networks and it passes through an 1532 unsecured SP, POP, NAP, or IX, then security mechanisms MUST be 1533 employed. These security mechanisms include encryption, 1534 authentication and resource protection as described in section 6.9 1535 and security management of section 7.5. For example, a provider 1536 should consider use of both authentication and encryption for a 1537 tunnel used as part of a L3VPN that traverses another service 1538 provider's network. 1540 6.11 L3VPN Wholesale 1541 The architecture MUST support the possibility of one service 1542 provider offering VPN service to another service provider. Another 1543 example is when one service provider sells L3VPN service at 1544 wholesale to another service provider, who then resells that VPN 1545 service to his or her customers. 1547 Carugi, McDysan et al Informational - Expires January 2005 29 1549 Service requirements for Layer 3 PPVPNs July 2004 1551 The wholesaler's VPN MUST be transparent to the addressing and 1552 routing used by the reseller. 1554 Support for additional levels of hierarchy, for example three levels 1555 where a reseller can again resell the VPN service to yet another VPN 1556 provider, SHOULD be provided. 1558 The Carrier's Carrier scenario is the name used in this document for 1559 this category of L3VPN wholesale (although some scenarios of Inter- 1560 AS/Inter-Provider VPN could possibly fall in this L3VPN wholesale 1561 category too). Various carrier's carrier scenarios should be 1562 supported, such as: 1563 - the customer Carriers do not operate L3VPN services for their 1564 clients; 1565 - the customer Carriers operate L3VPN services for their clients, 1566 but these services are not linked with the L3VPN service offered 1567 by the Carrier's Carrier; 1568 - the customer Carriers operate L3VPN services for their clients and 1569 these services are linked with the L3VPN service offered by the 1570 Carrier's Carrier ("Hierarchical VPNs" scenario) 1572 6.12 Tunneling Requirements 1573 Connectivity between CE sites or PE devices in the backbone SHOULD 1574 be able to use a range of tunneling technologies, such as L2TP, 1575 IPSEC, GRE, IP-in-IP, MPLS, etc. 1577 To set up tunnels between routers, every router MUST support static 1578 configuration for tunneling and MAY support a tunnel setup protocol. 1579 If employed, a tunnel establishment protocol SHOULD be capable of 1580 conveying information, such as the following: 1581 - Relevant identifiers 1582 - QoS/SLA parameters 1583 - Restoration parameters 1584 - Multiplexing identifiers 1585 - Security parameters 1587 There MUST be a means to monitor the following aspects of tunnels: 1588 - Statistics, such as amount of time spent in the up and down 1589 state 1590 - Count of transitions between the up and down state 1591 - Events, such as transitions between the up and down states 1593 The tunneling technology used by the VPN Service Provider and its 1594 associated mechanisms for tunnel establishment, multiplexing, and 1595 maintenance MUST meet the requirements on scaling, isolation, 1596 security, QoS, manageability, etc. 1598 6.13 Support for Access and Backbone Technologies 1599 This section describes requirements for aspects of access and 1600 backbone network technologies from an SP point of view. 1602 Carugi, McDysan et al Informational - Expires January 2005 30 1604 Service requirements for Layer 3 PPVPNs July 2004 1606 Some SPs MAY desire that a single network infrastructure should 1607 suffice for all services, public IP, VPNs, traffic engineering, and 1608 differentiated services [L2 VPN]. 1610 6.13.1 Dedicated Access Networks 1611 Ideally, the L3VPN service SHOULD be independent of physical, link 1612 layer or even network technology of the access network. However, the 1613 characteristics of access networks MUST be accounted for when 1614 specifying the QoS aspects of SLAs for VPN service offerings. 1616 6.13.2 On-Demand Access Networks 1617 Service providers SHOULD be able to support temporary user access, 1618 as described in section 5.11.2 using dedicated or dial-in access 1619 network technology. 1621 L3VPN solutions MUST support the case where a VPN user directly 1622 accesses the VPN service through an access network connected to the 1623 service provider. They MUST also describe how they can support the 1624 case where one or more other service provider networks are used as 1625 access to the service provider supporting the L3VPN service. 1627 Ideally, all information necessary to identify and authenticate 1628 users for an intranet SHOULD be stored and maintained by the 1629 customer. In an extranet, one customer SHOULD be able to maintain 1630 the authentication server, or the customers involved in the extranet 1631 MAY choose to outsource the function to a service provider. 1633 Identification and authentication information could be made 1634 available to the service provider for controlling access, or the 1635 service provider may query a customer maintained server. 1636 Furthermore, one SP may act as access for the SP providing the VPN 1637 service. In the case where the access SP performs identification and 1638 authentication on behalf of the VPN SP, an agreement MUST be reached 1639 on a common specification. 1641 Support for at least the following authentication protocols SHALL be 1642 supported: PAP, CHAP and EAP, since they are currently used in a 1643 wide range of equipment and services. 1645 6.13.3 Backbone Networks 1646 Ideally, the backbone interconnecting SP PE and P devices SHOULD be 1647 independent of physical and link layer technology. Nevertheless, the 1648 characteristics of backbone technology MUST be taken into account 1649 when specifying the QoS aspects of SLAs for VPN service offerings. 1651 6.14 Protection, Restoration 1652 When primary and secondary access connections are available, a L3VPN 1653 solution MUST provide restoration of access connectivity whenever 1654 the primary access link from a CE site to a PE fails. This 1655 restoration capability SHOULD be as automatic as possible, that is, 1656 the traffic should be directed over the secondary link soon after 1657 failure of the primary access link is detected. Furthermore, 1659 Carugi, McDysan et al Informational - Expires January 2005 31 1661 Service requirements for Layer 3 PPVPNs July 2004 1663 reversion to the primary link SHOULD be dynamic, if configured to do 1664 so [VPN-NEEDS]. 1666 As mentioned in Section 5.11.4 above, in the case of multi-homing, 1667 the load balancing capability MAY be used to achieve a degree of 1668 redundancy in the network. In the case of failure of one or more 1669 (but not all) of the multi-homed links, the load balancing 1670 parameters MAY be dynamically adjusted to rapidly redirect the 1671 traffic from the failed link(s) to the surviving links. Once the 1672 failed link(s) is (are) restored, the original provisioned load 1673 balancing ratio SHOULD be restored to its value prior to the 1674 failure. 1676 An SP SHOULD be able to deploy protection and restoration mechanisms 1677 within his or her backbone infrastructure to increase reliability 1678 and fault tolerance of the VPN service offering. These techniques 1679 SHOULD be scalable, and therefore should strive to not perform such 1680 function in the backbone on a per-VPN basis. 1682 Appropriate measurements and alarms that indicate how well network 1683 protection and restoration mechanisms are performing MUST be 1684 supported. 1686 6.15 Interoperability 1687 Service providers are interested in interoperability in at least the 1688 following scenarios: 1689 - To facilitate use of PE and managed CE devices within a single SP 1690 network 1691 - To implement L3VPN services across two or more interconnected SP 1692 networks 1693 - To achieve interworking or interconnection between customer sites 1694 using different L3VPN approaches or different implementations of 1695 the same approach 1697 Each approach MUST describe whether any of the above objectives can 1698 be met. If an objective can be met, the approach MUST describe how 1699 such interoperability could be achieved. In particular, the approach 1700 MUST describe the inter-solution network interface, encapsulation 1701 method(s), routing protocol(s), security, isolation, management, and 1702 all other applicable aspects of the overall VPN solution provided 1703 [VPN IW]. 1705 6.16 Migration Support 1706 Service providers MUST have a graceful means to migrate a customer 1707 with minimal service disruption on a site-by-site basis to a L3VPN 1708 approach. 1710 If L3VPN approaches can interwork or interconnect, then service 1711 providers MUST have a graceful means to migrate a customer with 1712 minimal service disruption on a site-by-site basis whenever changing 1713 interworking or interconnection. 1715 Carugi, McDysan et al Informational - Expires January 2005 32 1717 Service requirements for Layer 3 PPVPNs July 2004 1719 7 Service Provider Management Requirements 1720 A service provider MUST have a means to view the topology, 1721 operational state, order status, and other parameters associated 1722 with each customer's VPN. Furthermore, an SP MUST have a means to 1723 view the underlying logical and physical topology, operational 1724 state, provisioning status, and other parameters associated with the 1725 equipment providing the VPN service(s) to its customers. 1727 Currently, proprietary methods are often used to manage VPNs. The 1728 additional expense associated with operators having to use multiple 1729 proprietary management methods (e.g., command line interface (CLI) 1730 languages) to access such systems is undesirable. Therefore, devices 1731 SHOULD provide standards-based interfaces wherever feasible. 1733 The remainder of this section presents detailed SP management 1734 requirements for a Network Management System (NMS) in the 1735 traditional fault, configuration, accounting, performance, and 1736 security (FCAPS) management categories. Much of this text was 1737 adapted from ITU-T Y.1311.1. 1739 7.1 Fault management 1740 Support for fault management includes: 1741 - indication of customers impacted by failure, 1742 - fault detection (incidents reports, alarms, failure 1743 visualization), 1744 - fault localization (analysis of alarms reports, diagnostics), 1745 - incident recording or logs, creation and follow through of trouble 1746 tickets), 1747 - corrective actions (traffic, routing, resource allocation). 1749 Since PE-based VPNs rely on a common network infrastructure, the NMS 1750 MUST provide a means to inform the provider on the VPN customers 1751 impacted by a failure in the infrastructure. The NMS SHOULD provide 1752 pointers to the related customer configuration information to aid in 1753 fault isolation and the determination of corrective action. 1755 It is desirable to detect faults caused by configuration errors, 1756 because these may cause VPN service to fail, or not meet other 1757 requirements (e.g., traffic and routing isolation). This is a 1758 likely case of compromised security [VPNSEC]. Detection of such 1759 errors is inherently difficult because the problem involves more 1760 than one node and may reach across a global perspective. One 1761 approach could be a protocol that systematically checks that all 1762 constraints and consistency checks hold among tunnel configuration 1763 parameters at the various end points. 1765 A capability to verify L3 reachability within a VPN MUST be provided 1766 for diagnostic purposes. 1768 A capability to verify the parameter configuration of a device 1769 supporting a L3VPN MUST be provided for diagnostic purposes. 1771 Carugi, McDysan et al Informational - Expires January 2005 33 1773 Service requirements for Layer 3 PPVPNs July 2004 1775 7.2 Configuration Management 1776 Overall, the NMS must support configuration necessary to realize 1777 desired L3 reachability of a L3VPN. Toward this end, an NMS MUST 1778 provide configuration management to provision at least the following 1779 L3VPN components: PE,CE, hierarchical tunnels, access connections, 1780 routing, and QoS, as detailed in this section. If shared access to 1781 the Internet is provided, then this option MUST also be 1782 configurable. 1784 Since VPN configuration and topology are highly dependent upon a 1785 customer's organization, provisioning systems MUST address a broad 1786 range of customer specific requirements. The NMS MUST ensure that 1787 these devices and protocols are provisioned consistently and 1788 correctly. 1790 Provisioning for adding or removing sites SHOULD be as localized and 1791 automated as possible. 1793 Configuration management for VPNs, according to service templates 1794 defined by the provider MUST be supported. A service template 1795 contains fields which, when instantiated, yield a definite service 1796 requirement or policy. For example, a template for an IPSec tunnel 1797 would contain fields such as tunnel end points, authentication 1798 modes, encryption and authentication algorithms, pre-shared keys if 1799 any, and traffic filters. An SLA template would contain fields such 1800 as delay, jitter, throughput and packet loss thresholds as well as 1801 end points over which the SLA has to be satisfied. In general, a 1802 customer's service order can be regarded as a set of instantiated 1803 service templates. This set can, in turn, be regarded as the logical 1804 or service architecture of the customer's VPN. 1806 Service templates can also be used by the provider to define the 1807 service architecture of the provider's own network. For example, 1808 OSPF templates could contain fields such as the subnets that form a 1809 particular area, the area identifier and the area type. BGP service 1810 template could contain fields which when instantiated would yield a 1811 BGP policy, such as for expressing a preference about an exit router 1812 for a particular destination. 1814 The set of service templates SHOULD be comprehensive in that they 1815 can capture all service orders in some meaningful sense. 1817 The provider SHOULD provide means for translating instantiated 1818 service templates into device configurations so that associated 1819 services can be provisioned. 1821 Finally, the approach SHOULD provide means for checking if a service 1822 order is correctly provisioned. This would represent one method of 1823 diagnosing configuration errors. Configuration errors can arise due 1824 to a variety of reasons: manual configuration, intruder attacks, and 1825 conflicting service requirements. 1827 Carugi, McDysan et al Informational - Expires January 2005 34 1829 Service requirements for Layer 3 PPVPNs July 2004 1831 7.2.1 Configuration Management for PE-Based VPNs 1832 Requirements for configuration management unique to a PE-based VPN 1833 are as follows. 1835 o The NMS MUST support configuration of at least the following 1836 aspects of a L3 PE routers: intranet and extranet membership, CE 1837 routing protocol for each access connection, routing metrics, 1838 tunnels, etc. 1840 o The NMS SHOULD use identifiers for SPs, L3VPNs, PEs, CEs, 1841 hierarchical tunnels and access connections as described in section 1842 6.3. 1844 o Tunnels MUST be configured between PE and P devices. This 1845 requires coordination of identifiers of tunnels, hierarchical 1846 tunnels, VPNs, and any associated service information, for example a 1847 QoS/SLA service. 1849 o Routing protocols running between PE routers and CE devices MUST 1850 be configured per VPN. 1852 O For multicast service, multicast routing protocols MUST also be 1853 configurable. 1855 o Routing protocols running between PE routers and between PE and P 1856 routers MUST also be configured. 1858 o The configuration of a PE-based L3VPN MUST be coordinated with the 1859 configuration of the underlying infrastructure, including Layer 1 1860 and 2 networks interconnecting components of a L3VPN. 1862 7.2.2 Configuration management for CE-based VPN 1863 Requirements for configuration management unique to a CE-based VPN 1864 are as follows. 1866 o Tunnels MUST be configured between CE devices. This requires 1867 coordination of identifiers of tunnels, VPNs, and any associated 1868 service information, for example, a QoS/SLA service. 1870 o Routing protocols running between PE routers and CE devices MUST 1871 be configured. For multicast service, multicast routing protocols 1872 MUST also be configurable. 1874 7.2.3 Provisioning Routing 1875 A means for a service provider to provision parameters for the IGP 1876 for a L3VPN MUST be provided. This includes link level metrics, 1877 capacity, QoS capability, and restoration parameters. 1879 7.2.4 Provisioning Network Access 1880 A service provider MUST have the means to provision network access 1881 between SP-managed PE and CE, as well as the case where the customer 1882 manages the CE. 1884 Carugi, McDysan et al Informational - Expires January 2005 35 1886 Service requirements for Layer 3 PPVPNs July 2004 1888 7.2.5 Provisioning Security Services 1889 When a security service is requested, an SP MUST have the means to 1890 provision the entities and associated parameters involved with the 1891 service. For example, for IPsec service, tunnels, options, keys, and 1892 other parameters must be provisioned at either the CE and/or PE. In 1893 the case of an intrusion detection service, the filtering and 1894 detection rules must be provisioned on a VPN basis. 1896 7.2.6 Provisioning VPN Resource Parameters 1897 A service provider MUST have a means to dynamically provision 1898 resources associated with VPN services. For example, in a PE-based 1899 service, the number and size of virtual switching and forwarding 1900 table instances must be provisionable. 1902 Dynamic VPN resource assignment is crucial to cope with the frequent 1903 changes requests from customer's (e.g., sites joining or leaving a 1904 VPN), as well as to achieve scalability. The PEs SHOULD be able to 1905 dynamically assign the VPN resources. This capability is especially 1906 important for dial and wireless VPN services. 1908 If an SP supports a "Dynamic Bandwidth management" service, then the 1909 provisioning system MUST be able to make requested changes within 1910 the ranges and bounds specified in the Service Level Agreement 1911 (SLA). Examples of SLA parameters are response time and probability 1912 of being able to service such a request. 1914 7.2.7 Provisioning Value-Added Service Access 1915 A L3VPN service provides controlled access between a set of sites 1916 over a common backbone. However, many service providers also offer a 1917 range of value-added services, for example: Internet access, 1918 firewall services, intrusion protection, IP telephony and IP 1919 Centrex, application hosting, backup, etc. It is outside of the 1920 scope of this document to define if and how these different services 1921 interact with the VPN in order to solve issues such as addressing, 1922 integrity and security. However, the VPN service MUST be able to 1923 provide access to these various types of value-added services. 1925 A VPN service SHOULD allow the SP to supply the customer with 1926 different kinds of standard IP services, like DNS, NTP and RADIUS 1927 needed for ordinary network operation and management. The provider 1928 SHOULD be able to provide IP services to multiple VPN customers. 1930 A firewall function MAY be required to restrict access to the L3VPN 1931 from the Internet [Y.1311]. 1933 A managed firewall service MUST be carrier grade. For redundancy and 1934 failure recovery, a means for firewall fail-over should be provided. 1935 Managed firewall services that may be provided include dropping 1936 specified protocol types, intrusion protection, traffic-rate 1937 limiting against malicious attacks, etc. 1939 Carugi, McDysan et al Informational - Expires January 2005 36 1941 Service requirements for Layer 3 PPVPNs July 2004 1943 Managed firewalls MUST be supported on a per-VPN basis, although 1944 multiple VPNs may be supported by the same physical device (e.g., in 1945 PE-based solution). Managed firewalls SHOULD be provided at the 1946 major access point(s) for the L3VPN. Managed firewall services may 1947 be embedded in CE or PE device, or implemented in standalone 1948 devices. 1950 The NMS SHOULD allow a customer to outsource the management of an IP 1951 networking service to the SP providing the VPN or to a third party. 1953 The NMS SHOULD support collection of information necessary for 1954 optimal allocation of IP services in response to customer orders. 1956 Reachability to and from the Internet to sites within a VPN MUST be 1957 configurable by an SP. This could be controlled by configuring 1958 routing policy to control distribution of VPN routes advertised to 1959 the Internet. 1961 7.2.8 Provisioning Hybrid VPN Services 1962 Configuration of interworking or interconnection between L3VPN 1963 solutions SHOULD be also supported. Ensuring that security and end- 1964 to-end QoS issues are provided consistently SHOULD be addressed. 1966 7.3 Accounting 1967 Many service providers require collection of measurements regarding 1968 resource usage for accounting purposes. The NMS MAY need to 1969 correlate accounting information with performance and fault 1970 management information to produce billing that takes into account 1971 SLA provisions for periods of time where the SLS is not met. 1973 A L3VPN solution MUST describe how the following accounting 1974 functions can be provided: 1975 - measurements of resource utilization, 1976 - collection of accounting information, 1977 - storage and administration of measurements. 1979 Some providers may require near-real time reporting of measurement 1980 information, and may offer this as part of a customer network 1981 management service. 1983 If an SP supports a "Dynamic Bandwidth management" service, then the 1984 dates, times, amounts and interval required to perform requested 1985 bandwidth allocation change(s) MUST be traceable for monitoring and 1986 accounting purposes. 1988 Solutions should state compliance to accounting requirements, as 1989 described in section 1.7 of RFC 2975. 1991 Carugi, McDysan et al Informational - Expires January 2005 37 1993 Service requirements for Layer 3 PPVPNs July 2004 1995 7.4 Performance Management 1996 Performance management MUST support functions involved with 1997 monitoring and collecting performance data regarding devices, 1998 facilities, and services, as well as determination of conformance to 1999 Service Level Specifications (SLS), such as QoS and availability 2000 measurements. 2002 Performance management SHOULD also support analysis of important 2003 aspects of a L3VPN , such as bandwidth utilization, response time, 2004 availability, QoS statistics, and trends based on collected data. 2006 7.4.1 Performance Monitoring 2007 The NMS MUST monitor device behavior to evaluate performance metrics 2008 associated with an SLA. Different measurement techniques may be 2009 necessary depending on the service for which an SLA is provided. 2010 Example services are QoS, security, multicast, and temporary access. 2011 These techniques MAY be either intrusive or non-intrusive depending 2012 on the parameters being monitored. 2014 The NMS MUST also monitor aspects of the VPN not directly associated 2015 with an SLA, such as resource utilization, state of devices and 2016 transmission facilities, as well as control of monitoring resources 2017 such as probes and remote agents at network access points used by 2018 customers and mobile users. 2020 7.4.2 SLA and QoS management features 2021 The NMS SHOULD support SLAs between an SP and the various VPN 2022 customers according to the corresponding SLSes by measurement of the 2023 indicators defined within the context of the SLA, on a regular 2024 basis. 2026 The NMS SHOULD use the QOS parameter measurement definitions, 2027 techniques, and methods as defined by the IETF IP Performance 2028 Metrics (IPPM) working group for delay, loss, and delay variation. 2030 The NMS SHOULD support allocation and measurement of end-to-end QoS 2031 requirements to QoS parameters for one or more VPN network(s). 2033 Devices supporting L3VPN SLAs SHOULD have real-time performance 2034 measurements that have indicators and threshold crossing alerts. 2035 Such thresholds should be configurable. 2037 7.5 Security Management 2038 The security management function of the NMS MUST include management 2039 features to guarantee the security of devices, access connections, 2040 and protocols within the L3VPN network(s), as well as the security 2041 of customer data and control as described in section 6.9. 2043 7.5.1 Resource Access Control 2044 Resource access control determines the privileges that a user has to 2045 access particular applications and VPN network resources. Without 2046 such control, only the security of the data and control traffic is 2048 Carugi, McDysan et al Informational - Expires January 2005 38 2050 Service requirements for Layer 3 PPVPNs July 2004 2052 protected, leaving the devices providing the L3VPN network 2053 unprotected. Access control capabilities protect these devices to 2054 ensure that users have access to only the resources and applications 2055 to which they are authorized to use. 2057 In particular, access to the routing and switching resources managed 2058 by the SP MUST be tightly controlled to prevent and/or effectively 2059 mitigate a malicious attack. More detailed requirements in this area 2060 are described in [VPNSEC]. 2062 7.5.2 Authentication 2063 Authentication is the process of verifying that the sender is 2064 actually who he or she claims to be. The NMS MUST support standard 2065 methods for authenticating users attempting to access management 2066 services. 2068 Scalability is critical as the number of nomadic/mobile clients is 2069 increasing rapidly. The authentication scheme implemented for such 2070 deployments MUST be manageable for large numbers of users and VPN 2071 access points. 2073 Strong authentication schemes SHALL be supported to ensure the 2074 security of both VPN access point-to-VPN access point (e.g., PE to 2075 PE in a PE-based case) and client-to-VPN Access point (e.g., CE-to- 2076 PE in a PE-based case) communications. This is particularly 2077 important to prevent VPN access point spoofing. VPN Access Point 2078 Spoofing is the situation where an attacker tries to convince a PE 2079 or CE that the attacker is the VPN Access Point. If an attacker can 2080 convince a PE or CE device of that, then that device will send VPN 2081 traffic to the attacker (who could forward it to the true access 2082 point after compromising confidentiality or integrity).In other 2083 words, a non-authenticated VPN AP can be spoofed with a man-in-the- 2084 middle attack, because the endpoints never verify each other. A 2085 weakly-authenticated VPN AP may be subject to such an attack. 2086 Strongly-authenticated VPN APs are not subject to such attacks, 2087 because the man-in-the-middle cannot be authenticated as the real 2088 AP, due to the strong authentication algorithms. 2090 7.6 Basis and Presentation Techniques of Management Information 2091 Each L3VPN solution approach MUST specify the management information 2092 bases (MIB) modules for the network elements involved in L3VPN 2093 services. This is an essential requirement in network provisioning. 2094 The approach SHOULD identify any information not contained in a 2095 standard MIB related to FCAPS that is necessary to meet a generic 2096 requirement. 2098 An IP VPN (Policy)Information model, when available, SHOULD reuse 2099 the policy information models being developed in parallel for 2100 specific IP network capabilities [IM-REQ]. This includes the QoS 2101 Policy Information Model_[QPIM] and the IPSEC Configuration Policy 2102 Model_ [IPSECIM]. The IP VPN Information model SHOULD provide the 2103 OSS with adequate "hooks" to correlate service level specifications 2105 Carugi, McDysan et al Informational - Expires January 2005 39 2107 Service requirements for Layer 3 PPVPNs July 2004 2109 with traffic data collected from network elements. The use of 2110 policies includes rules that control corrective actions taken by OSS 2111 components responsible for monitoring the network and ensuring that 2112 it meets service requirements. 2114 Additional requirements on VPN information models are given in 2115 reference [IM-PPVPN]. In particular, an information model MUST allow 2116 an SP to change VPN network dimensions with minimal influence on 2117 provisioning issues. The adopted model SHOULD be applicable to both 2118 small/medium size and large-scale L3VPN scenarios. 2120 Some service providers MAY require systems that visually, audibly, 2121 or logically present FCAPS information to internal operators and/or 2122 customers. 2124 8 Security Considerations 2125 Security considerations occur at several levels and dimensions 2126 within L3 VPNs, as detailed within this document. This section 2127 provides a summary with references to supporting detailed 2128 information. 2130 The requirements in this document separate the notion of traditional 2131 security requirements, such as integrity, confidentiality, and 2132 authentication from that of isolating (or separating) the exchange 2133 of VPN data and control traffic between specific sets of sites (as 2134 defined in sections 3.3 and 4.1). Further detail on security 2135 requirements is given from the customer and service provider 2136 perspectives in sections 5.9 and 6.9, respectively. In an analogous 2137 manner, further detail on data and control traffic isolation 2138 requirements are given from the customer and service provider 2139 perspectives in sections 5.1 and 6.8, respectively. Additionally, 2140 references to a document [VPNSEC] specifically addressing security 2141 requirements are made where appropriate. 2143 Furthermore, requirements regarding management of security from a 2144 service provider perspective are described in section 7.5. 2146 9 Acknowledgements 2147 The authors of this document would like to acknowledge the 2148 contributions from the people who launched the work on VPN 2149 requirements inside ITU-T SG13, the authors of the original IP VPN 2150 requirements and framework document [RFC 2764], as well as Tom 2151 Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, 2152 Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le 2153 Garrec. The authors are also grateful to the helpful suggestions and 2154 direction provided by the technical advisors, Alex Zinin, Scott 2155 Bradner, Bert Wijnen and Rob Coltun. Finally, the authors also wish 2156 to acknowledge the insights and requirements gleaned from the many 2157 documents listed in the references section. Citations to these 2158 documents were made only where the authors believed that additional 2159 insight to the requirement could be obtained by reading the source 2160 document. 2162 Carugi, McDysan et al Informational - Expires January 2005 40 2164 Service requirements for Layer 3 PPVPNs July 2004 2166 10 References 2168 10.1 Normative References 2169 [RFC 3809] Nagarajan, A., "Generic Requirements for Provider 2170 Provisioned VPN," Work in Progress. 2171 [RFC 3377] Hodges, J., Morgan, R. "Lightweight Directory Access 2172 Protocol (v3): Technical Specification," RFC 3377, 2173 September 2002 2174 [RFC 1918] Rekhter, Y., et al., "Address Allocation for Private 2175 Internets," RFC 1918, February 1996. 2176 [RFC 2026] Bradner, S., "The Internet Standards Process -- 2177 Revision 3", BCP 9, RFC 2026, October 1996. 2178 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 2179 Requirement Levels", BCP 14, RFC 2119, March 1997 2180 [RFC 2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., 2181 Jamin, S. "Resource ReSerVation Protocol (RSVP) -- 2182 Version 1 Functional Specification," September 1997. 2183 [RFC 2211] Wroclawski, J., Specification of the Controlled-Load 2184 Network Element Service, RFC 2211, IETF, September 2185 1997. 2186 [RFC 2212] Shenker, S., Partridge, C., Guerin, R., Specification 2187 of Guaranteed Quality of Service, RFC 2212, IETF, 2188 September 1997. 2189 [RFC 2251] Wahl, M. et al., "Lightweight Directory Access 2190 Protocol (v3)," RFC 2251, December 1997. 2191 [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, 2192 Z., Weiss, W. "An Architecture for Differentiated 2193 Services", RFC 2475, Dec. 1998. 2194 [RFC 2597] Baker, F., Heinanen, J., Weiss, W., Wroclawski, J. 2195 "Assured Forwarding PHB Group", RFC 2597, June 1999. 2196 [RFC 2661] Townsley, W. et al., "Layer Two Tunneling Protocol 2197 "L2TP"," RFC 2661, August 1999. 2198 [RFC 2685] Fox B., et al, "Virtual Private Networks Identifier", 2199 RFC 2685, September 1999. 2200 [RFC 2983] Black, D. "Differentiated Services and Tunnels," 2201 RFC2983, October 2000 2202 [RFC 3031] Rosen, E., Viswanathan, A., Callon, R. "Multiprotocol 2203 Label Switching Architecture," January 2001. 2204 [RFC 3246] Davie, B., et al., "An Expedited Forwarding PHB", RFC 2205 3246, March 2002. 2206 [RFC 3270] Le Faucheur, F., et al., "Multi-Protocol Label 2207 Switching (MPLS) Support of Differentiated Services," 2208 RFC 3270, May 2002 2210 10.2 Non-normative References 2211 [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work 2212 in progress. 2213 [2917bis] Muthukrishnan, K., et al., "A Core MPLS IP VPN 2214 Architecture," work in progress 2216 Carugi, McDysan et al Informational - Expires January 2005 41 2218 Service requirements for Layer 3 PPVPNs July 2004 2220 [DOCSIS 1.1] Data Over Cable Service Interface Specification 2221 (DOCSIS), Cable Labs, 2222 http://www.cablemodem.com/specifications.html 2223 [FRF.13] Frame Relay Forum, "Service Level Definitions 2224 Implementation Agreement," August, 1998. 2225 [IM-PPVPN] Lago, P., et al., "An Information Model for Provider 2226 Provisioned Virtual Private Networks," work in 2227 progress. 2228 [IM-REQ] Iyer, M., et al., "Requirements for an IP VPN Policy 2229 Information Model," work in progress 2230 [IPSECIM] Jason, J., "IPsec Configuration Policy Model," work 2231 in progress. 2232 [CE-PPVPN] De Clercq, J., Paridaens, O., Krywaniuk, A., Wang, 2233 C., "An Architecture for Provider Provisioned CE- 2234 based Virtual Private Networks using IPsec," work in 2235 progress 2236 [IPSEC-PPVPN] Gleeson, B., "Uses of IPsec with Provider 2237 Provisioned VPNs," work in progress. 2238 [L2 MPLS] Martini, L., et al., "Transport of Layer 2 Frames 2239 Over MPLS," work in progress. 2240 [L2 VPN] Rosen, E., et al., "An Architecture for L2VPNs," 2241 work in progress. 2242 [L2 VPN] Kompella, K., Bonica, R., "Whither Layer 2 VPNs?," 2243 work in progress. 2244 [MPLS SEC] Behringer, M., "Analysis of the Security of the MPLS 2245 Architecture," work in progress 2246 [PPVPN-TERM] Andersson, L., Madsen, T., "PPVPN Terminology," work 2247 in progress 2248 [L3VPN-SEC] Fang, L., et al., "Security Framework for Provider 2249 Provisioned Virtual Private Networks," work in 2250 progress. 2251 [NBVPN-FR] Suzuki, M. and Sumimoto, J. (editors), "A framework 2252 for Network-based VPNs", work in progress 2253 [L3VPN-FR] Callon, R., Suzuki, M., et al. "A Framework for 2254 Layer 3 Provider Provisioned Virtual Private 2255 Networks ",work in progress 2256 [PPVPN-VR] Knight, P., Ould-Brahim, H., Gleeson, B., "Network 2257 based IP VPN Architecture using Virtual 2258 Routers," work in progress 2259 [QPIM] Snir, Ramberg, Strassner, Cohen and Moore, "Policy 2260 QoS Information Model," work in progress. 2261 [RFC 2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs," RFC 2547, 2262 March 1999. 2263 [RFC 2764] Gleeson, B., et al., "A Framework for IP based Virtual 2264 Private Networks", RFC 2764, February 2000. 2265 [RFC 2975] Aboba, B., et al., "Introduction to Accounting 2266 Management," October 2000. 2267 [RFC 3198] Westerinen, A., et al., "Terminology for Policy-Based 2268 Management," November, 2001. 2269 [TE-INTERAS] Zhang, R., Vasssuer, J.P., "MPLS Inter-AS Traffic 2270 Engineering requirements," work in progress. 2271 [VPN DISC] Squire, M. et al., "VPN Discovery Discussions and 2273 Carugi, McDysan et al Informational - Expires January 2005 42 2275 Service requirements for Layer 3 PPVPNs July 2004 2277 Options," work in progress. 2278 [VPN IW] Kurakami, H., et al., "Provider-Provisioned VPNs 2279 Interworking," work in progress. 2280 [VPN SEC] De Clercq, J., et al., "Considerations about 2281 possible security extensions to BGP/MPLS VPN," work 2282 in progress. 2283 [VPN TUNNEL] Worster, T., et al., "A PPVPN Layer Separation: VPN 2284 Tunnels and Core Connectivity," work in progress 2285 [VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V., 2286 "Criteria for Evaluating VPN Implementation 2287 Mechanisms", work in progress 2288 [VPN-NEEDS] Jacquenet, C., "Functional needs for the deployment 2289 of an IP VPN service offering : a service provider 2290 perspective ", work in progress 2291 [Y.1241] "IP Transfer Capability for the support of IP based 2292 Services", Y.1241 ITU-T Recommendation, January 2293 2001. 2294 [Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS 2295 architecture",Y.1311.1 ITU-T Recommendation, 2296 July2001. 2297 [Y.1311] Knightson, K. (editor), "Network based VPNs - 2298 Generic Architecture and Service Requirements," 2299 Y.1311 ITU-T Recommendation, March 2002. 2301 11 Authors' address 2303 Marco Carugi (Co-editor) 2304 Nortel Networks 2305 Parc d'activit�s de Magny-Les Jeunes Bois CHATEAUFORT 2306 78928 YVELINES Cedex 9 - FRANCE 2307 EMail: marco.carugi@nortelnetworks.com 2309 Dave McDysan (Co-editor) 2310 MCI 2311 22001 Loudoun County Parkway 2312 Ashburn, VA 20147, USA 2313 EMail: dave.mcdysan@mci.com 2315 Luyuan Fang 2316 AT&T 2317 200 Laurel Ave - Room C2-3B35 2318 Middletown, NJ 07748 USA 2319 EMail: Luyuanfang@att.com 2321 Ananth Nagarajan 2322 Juniper Networks 2323 EMail: ananth@juniper.net 2325 Junichi Sumimoto 2326 NTT Communications Corporation 2327 3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan 2328 EMail: j.sumimoto@ntt.com 2330 Carugi, McDysan et al Informational - Expires January 2005 43 2332 Service requirements for Layer 3 PPVPNs July 2004 2334 Rick Wilder 2335 Alcatel 2336 EMail: rick.wilder@alcatel.com 2338 Full copyright statement 2340 Copyright (C) The Internet Society (1999). All Rights Reserved. 2342 This document and translations of it may be copied and furnished to 2343 others, and derivative works that comment on or otherwise explain it 2344 or assist its implementation may be prepared, copied, published and 2345 distributed, in whole or in part, without restriction of any kind, 2346 provided that the above copyright notice and this paragraph are 2347 included on all such copies and derivative works. However, this 2348 document itself may not be modified in any way, such as by removing 2349 the copyright notice or references to the Internet Society or other 2350 Internet organizations, except as needed for the purpose of 2351 developing Internet standards in which case the procedures for 2352 copyrights defined in the Internet Standards process must be 2353 followed, or as required to translate it into languages other than 2354 English. 2356 The limited permissions granted above are perpetual and will not be 2357 revoked by the Internet Society or its successors or assigns. 2359 This document and the information contained herein is provided on an 2360 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2361 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2362 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2363 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2364 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2366 Carugi, McDysan et al Informational - Expires January 2005 44