idnits 2.17.1 draft-ietf-l3vpn-mgt-fwk-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 951. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 958. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 964. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 752 has weird spacing: '... should be co...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 11, 2005) is 6948 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2975 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Downref: Normative reference to an Experimental RFC: RFC 2903 ** Downref: Normative reference to an Informational RFC: RFC 2906 ** Downref: Normative reference to an Informational RFC: RFC 3809 ** Downref: Normative reference to an Informational RFC: RFC 4026 Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Y. El Mghazli 3 Internet-Draft Alcatel 4 Expires: October 13, 2005 T. Nadeau 5 Cisco 6 M. Boucadair 7 France Telecom 8 K. Chan 9 Nortel 10 A. Gonguet 11 Alcatel 12 April 11, 2005 14 Framework for L3VPN Operations and Management 15 draft-ietf-l3vpn-mgt-fwk-08 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 13, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document provides a framework for operation and management of 49 Layer 3 Virtual Private Networks (L3VPNs). This framework intends to 50 produce a coherent description of the significant technical issues 51 that are important in the design of L3VPN management solutions. 52 Selection of specific approaches, making choices among information 53 models and protocols are outside of the scope of this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2 Management functions . . . . . . . . . . . . . . . . . . . 4 60 1.3 Reference Models . . . . . . . . . . . . . . . . . . . . . 5 61 2. Customer Service Operations and Management . . . . . . . . . . 8 62 2.1 Customer Service Management Information Model . . . . . . 8 63 2.2 Customer Management Functions . . . . . . . . . . . . . . 9 64 2.2.1 Fault Management . . . . . . . . . . . . . . . . . . . 9 65 2.2.2 Configuration Management . . . . . . . . . . . . . . . 10 66 2.2.3 Accounting . . . . . . . . . . . . . . . . . . . . . . 10 67 2.2.4 Performance Management . . . . . . . . . . . . . . . . 11 68 2.2.5 Security Management . . . . . . . . . . . . . . . . . 11 69 2.3 Customer Management Functional Description . . . . . . . . 11 70 2.3.1 L3VPN Service Offering Management . . . . . . . . . . 12 71 2.3.2 L3VPN Service Order Management . . . . . . . . . . . . 13 72 2.3.3 L3VPN Service Assurance . . . . . . . . . . . . . . . 13 73 3. Provider Network Manager . . . . . . . . . . . . . . . . . . . 14 74 3.1 Provider Network Management Definition . . . . . . . . . . 14 75 3.2 Network Management Functions . . . . . . . . . . . . . . . 14 76 3.2.1 Fault Management . . . . . . . . . . . . . . . . . . . 15 77 3.2.2 Configuration Management . . . . . . . . . . . . . . . 15 78 3.2.3 Accounting . . . . . . . . . . . . . . . . . . . . . . 18 79 3.2.4 Performance Management . . . . . . . . . . . . . . . . 18 80 3.2.5 Security Management . . . . . . . . . . . . . . . . . 19 81 4. L3VPN Devices . . . . . . . . . . . . . . . . . . . . . . . . 21 82 4.1 Information model . . . . . . . . . . . . . . . . . . . . 21 83 4.2 Communication . . . . . . . . . . . . . . . . . . . . . . 21 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 85 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 87 8. Normative References . . . . . . . . . . . . . . . . . . . . . 24 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 89 Intellectual Property and Copyright Statements . . . . . . . . 26 91 1. Introduction 93 1.1 Terminology 95 In this document, the following terms are used and defined as 96 follows: 98 VPN: 100 Virtual Private Network. A set of transmission and switching 101 resources, which will be used over a shared infrastructure to 102 process the (IP) traffic that characterizes communication services 103 between the sites or premises interconnected via this VPN. See 104 [RFC4026]. 106 L3VPN: 108 An L3VPN interconnects sets of hosts and routers based on Layer 3 109 addresses. See [RFC4026]. 111 VPN Instance: 113 From a management standpoint, a VPN instance is the collection of 114 configuration information associated with a specific VPN, residing 115 on a PE router. 117 VPN Site: 119 A VPN customer's location connected to the Service Provider 120 network via a CE-PE link, which can access at least one VPN. 122 VPN Service Provider (SP): 124 A Service Provider that offers VPN-related services. 126 VPN Customer: 128 Refers to a customer that bought VPNs from a VPN service provider. 130 Customer Agent: 132 Denotes the entity that is responsible for requesting VPN customer 133 specific information. 135 Service Level Agreement(SLA): 137 Contractual agreement between Service Provider and Customer, which 138 includes qualitative and quantative metrics defining service 139 quality guarantees and retribution procedures when service levels 140 are not being met. 142 Service Level Specifications (SLS): 144 Internally-focused service performance specifications used by the 145 Service Provider to manage customer service quality levels. 147 1.2 Management functions 149 For any type of Layer-3 VPN (PE or CE-based VPNs) it is recommended 150 to have a management platform where the VPN-related information could 151 be collected and managed. The Service and Network Management System 152 may centralize information related to instances of a VPN and allow 153 users to configure and provision each instance from a central 154 location. 156 An SP must be able to manage the capabilities and characteristics of 157 their VPN services. Customers should have means to ensure 158 fulfillment of the VPN service they subscribed to. To the extent 159 possible, automated operations and interoperability with standard 160 management protocols should be supported. 162 Two main management functions are identified: 164 A customer service management function: 166 This function provides the means for a customer to query, 167 configure, and receive (events/alarms) customer-specific VPN 168 service information. Customer-specific information includes data 169 related to contact, billing, site, access network, IP address, 170 routing protocol parameters, etc. It may also include 171 confidential data, such as encryption keys. Several solutions 172 could be used: 174 * Proprietary network management system 176 * SNMP manager 178 * PDP function 180 * Directory service, etc. 182 A provider network management function: 184 This function is responsible for planning, building, provisioning, 185 and maintaining network resources in order to meet the VPN 186 service-level agreements outlined in the SLA offered to the 187 customer. This mainly consists of (1) setup and configuration of 188 physical links, (2) provisioning of logical VPN service 189 configurations, and (3) life-cycle management of VPN service 190 including adding, modifying, and deleting VPN configurations. 192 There may be relationships between the customer service management 193 function and the provider network management function, as the 194 provider network is managed to support/realize/provide the 195 customer service. One example use of this relationship is to 196 provide the VPN-SLS assurance for verifying the fulfillment of the 197 subscribed VPN agreement. 199 1.3 Reference Models 201 The ITU-T Telecommunications Management Network has the following 202 generic requirements structure: 204 o Engineer, deploy and manage the switching, routing and 205 transmission resources supporting the service, from a network 206 perspective (network element management); 208 o Manage the VPNs deployed over these resources (network 209 management); 211 o Manage the VPN service (service management); 212 - - - - - - - - - - - - - - - - - - - - - - - -:- - - - - - - - - 213 Service +-------------+ : +----------+ 214 Management | Service |<------------------:----->| Customer | 215 Layer | Manager | : | Agent | 216 +-------------+ : +----------+ 217 - - - - - - - - - - ^ - - - - - - - - - - - - -:- - - - - - - - - 218 Network | +------------+ : 219 Management | | Provider | : 220 Layer | | Network | Customer 221 +------>| Manager | Interface 222 +------------+ : 223 - - - - - - - - - - - - - - - - - ^ - - - - - -:- - - - - - - - - 224 Network Element | : 225 Management | +------+ : +------+ 226 Layer | | | : | CE | 227 +->| PE | : |device| 228 |device| : | of | 229 | |--:--|VPN A| 230 +------+ : +------+ 231 ---------------------------------------------->:<---------------- 232 SP network : Customer Network 234 Figure 1: Reference Model for PE-based L3VPN Management 236 - - - - - - - - - - - - - - - - - - - - - - - -:- - - - - - - - - 237 Service +-------------+ : +----------+ 238 Management | Service |<------------------:----->| Customer | 239 Layer | Manager | : | Agent | 240 +-------------+ : +----------+ 241 - - - - - - - - - - ^ - - - - - - - - - - - - -:- - - - - - - - - 242 Network | +------------+ : 243 Management | | Provider | : 244 Layer | | Network | Customer 245 +------>| Manager | Interface 246 +------------+ : 247 - - - - - - - - - - - - - - - -^- - - -^- - - -:- - - - - - - - - 248 Network Element | +-------:---------------+ 249 Management | +------+ : +------+ | 250 Layer | | | : | CE | | 251 +---->| PE | : |device|<----+ 252 |device| : | of | 253 | |--:--|VPN A| 254 +------+ : +------+ 255 ---------------------------------------------->:<---------------- 256 SP network : Customer Network 258 Figure 2: Reference Model for CE-based L3VPN Management 260 Figure 1 and Figure 2 above present the reference models for both PE 261 and CE-based L3VPN management, according to the aforementioned 262 generic structure. 264 In both models, the service manager administrates customer-specific 265 attributes, such as customer Identifier (ID), personal information 266 (e.g., name, address, phone number, credit card number, etc.), 267 subscription services and parameters, access control policy 268 information, billing and statistical information, etc. 270 In the PE-based reference model, the provider network manager 271 administrates device attributes and their relationship, covering PE 272 devices and other devices constructing the corresponding PE-based 273 VPN. 275 In the CE-based reference model, the provider network manager 276 administrates device attributes and their relationship, covering PE 277 and CE devices constructing the corresponding CE-based VPN. 279 Network and customer service management systems that are responsible 280 for managing VPN networks have several challenges depending on the 281 type of VPN network(s) they are required to manage. 283 2. Customer Service Operations and Management 285 Services offered by providers can be viewed from the customer's or 286 the provider's perspectives. This section describes services 287 management from the customer's perspective, focusing on the Customer 288 Management function. 290 The Customer Management function's goal is managing the service-based 291 operations like service ordering, service subscription, activation, 292 etc. 294 The Customer Management function resides in the L3VPN service manager 295 at the Service Management Layer (SML). It mainly consists of 296 defining the L3VPN services offered by the SP, collecting and 297 consolidating the customer L3VPN services requirements, as well as 298 performing some reporting for the customer. This function is 299 correlated with the Network Management function at the Network 300 Management Layer (NML) for initiating the L3VPN services 301 provisioning, and getting some service reporting. 303 2.1 Customer Service Management Information Model 305 This section presents a framework that is used for L3VPN customer 306 service management at the SML. The information framework represent 307 the data that need to be managed, and the way they are represented. 308 At the SML, the information framework that is foreseen is composed of 309 Service Level Agreements (SLA) and Service Level Specifications 310 (SLS). 312 Services are described through Service Level Agreements (SLA) that 313 are contractual documents between customers and service providers. 314 The technical part of the service description is called the Service 315 Level Specification (SLS). The SLS groups different kinds of 316 parameters. Some are more related to the description of the 317 transport of the packets, and some to the specification of the 318 service itself. 320 A Service Level Specification (SLS) may be defined per access network 321 connection, per VPN, per VPN site, and/or per VPN route. The service 322 provider may define objectives and the measurement intervals for at 323 least the SLS using the following Service Level Objective (SLO) 324 parameters: 326 o QoS and traffic parameters 328 o Availability for the site, VPN, or access connection 329 o Duration of outage intervals per site, route or VPN 331 o Service activation interval (e.g., time to turn up a new site) 333 o Trouble report response time interval 335 o Time to repair interval 337 o Total incoming/outgoing traffic from a site, a (VPN) route or that 338 has transited through the whole VPN 340 o Measurement of non-conforming incoming/outgoing traffic 341 (compliance of traffic should deserve some elaboration, because of 342 many perspectives - security, QoS, routing, etc.) from a site, a 343 (VPN) route, or which has transited through the whole VPN 345 The service provider and the customer may negotiate contractual 346 penalties in the case(s) where the provider does not meet a (set of) 347 SLS performance objective(s). 349 Traffic parameters and actions should be defined for incoming and 350 outgoing packets that go through the demarcation between the service 351 provider premises and the customer's premises. For example, traffic 352 policing functions may be activated at the ingress of the service 353 provider's network, while traffic shaping capabilities could be 354 activated at the egress of the service provider's network. 356 2.2 Customer Management Functions 358 This section presents detailed customer management functions in the 359 traditional fault, configuration, accounting, performance, and 360 security (FCAPS) management categories. 362 2.2.1 Fault Management 364 The fault management function of the Customer Service Manager relies 365 upon the manipulation of network layer failure information, and it 366 reports incidents to the impacted customers. Such reports should be 367 based upon and relate to the VPN service offering subscribed by the 368 customer. The Customer Management function support for fault 369 management includes: 371 o Indication of customer's services impacted by failure, 373 o Incident recording or logs. 375 o Frequency of tests 376 o Ability to invoke probes from customer and provider 378 o Ability to uncover faults before the customer notices them 380 2.2.2 Configuration Management 382 The configuration management function of the Customer Manager must be 383 able to configure L3VPN service parameters with the level of detail 384 that the customer is able to specify, according to service templates 385 defined by the provider. 387 A service template contains fields which, when instantiated, yield a 388 definite service requirement or policy. For example, a template for 389 an IPsec tunnel [RFC2401] would contain fields such as tunnel end 390 points, authentication modes, encryption and authentication 391 algorithms, shared keys (if any), and traffic filters. 393 Other examples: a BGP/MPLS-based VPN service template would contain 394 fields such as the customer premises that need to be interconnected 395 via the VPN. And a QoS agreement template would contain fields such 396 as one-way transit delay, inter-packet delay variation, throughput, 397 and packet loss thresholds. 399 2.2.3 Accounting 401 The accounting management function of the Customer Manager is 402 provided with network layer measurements information and manages this 403 information. The Customer Manager is responsible for the following 404 accounting functions: 406 o Retrieval of accounting information from the Provider Network 407 Manager, 409 o Analysis, storage and administration of measurements. 411 Some providers may require near-real time reporting of measurement 412 information, and may offer this as part of a customer network 413 management service. 415 If a SP supports "Dynamic Bandwidth Management" service, then the 416 schedule and the amount of the bandwidth required to perform 417 requested bandwidth allocation change(s) must be traceable for 418 monitoring and accounting purposes. 420 Solutions should state compliance with accounting requirements, as 421 described in section 1.7 of [RFC2975]. 423 2.2.4 Performance Management 425 From the Customer Manager's perspective, performance management 426 includes functions involved in the determination of the conformance 427 level with the Service Level Specifications, such as QoS and 428 availability measurements. The objective is to correlate accounting 429 information with performance and fault management information to 430 produce billing that takes into account SLA provisions for periods of 431 time where the service level objectives are not met. 433 The performance information should reflect the quality of the 434 subscribed VPN service as perceived by the customer. This 435 information could be measured by the provider or controlled by a 436 third party. The parameters that will be used to reflect the 437 performance level could be negotiated and agreed between the service 438 provider and the customer during the VPN service negotiation phase. 440 Performance management should also support analysis of important 441 aspects of a L3VPN, such as bandwidth utilization, response time, 442 availability, QoS statistics, and trends based on collected data. 444 2.2.5 Security Management 446 From the Customer Manager's perspective, the security management 447 function includes management features to guarantee the security of 448 the VPN. This includes security of devices, configuration data and 449 access connections. Authentication and authorization (access 450 control) also fall into this category. 452 2.2.5.1 Access Control 454 Management access control determines the privileges that a user has 455 for particular applications and parts of the network. Without such 456 control, only the security of the data and control traffic is 457 protected, leaving the devices providing the L3VPN network 458 unprotected, among other equipment or resources. Access control 459 capabilities protect these devices to ensure that users have access 460 to the sole resources and applications they are granted to use. 462 2.2.5.2 Authentication 464 Authentication is the process of verifying the identity of a VPN 465 user. 467 2.3 Customer Management Functional Description 469 This section provides a high level example of an architecture for the 470 L3VPN management framework as far as the SML layer is concerned. The 471 goal is to map the customer management functions described in 472 Section 2.2 to architectural yet functional blocks, and to describe 473 the communication with the other L3VPN management functions. 475 + - - - - - - - - - - - - - - - - - - - - - - - - - + 476 | Service +----------------+ +----------------+ | 477 | Management | VPN Offering| | VPN Order | | 478 | | Management | | Management | | 479 | +----------------+ +----------------+ | 480 | +----------------+ +----------------+ | 481 | | VPN | | VPN-based | | 482 | | Assurance | | SLS Management | | 483 | +----------------+ +----------------+ | 484 + - - - - - - - - - - - - - - - - - - - - - - - - - + 486 Figure 3: Overview of the Service Management 488 A customer must have a means to view the topology, operational state, 489 order status, and other parameters associated with the VPN service 490 offering that has been subscribed. 492 All aspects of management information about CE devices and customer 493 attributes of a L3VPN manageable by a SP should be capable of being 494 configured and maintained by an authenticated, authorized Service 495 manager. 497 A customer agent should be able to make dynamic requests for changing 498 parameters describing a service. A customer should be able to 499 receive responses from the SP network in response to these requests 500 (modulo the existence of necessary agreements). Communication 501 between customer Agents and (VPN) service providers will rely upon a 502 query/response mechanism. 504 A customer who may not be able to afford the resources to manage its 505 CPEs should be able to outsource the management of the VPN to the 506 service provider(s) supporting the network. 508 2.3.1 L3VPN Service Offering Management 510 The deployment of a VPN hopefully addresses customers' requirements. 511 Thus, the provider must have the means to advertise the VPN-based 512 services it offers. Then, the potential customers could select the 513 service they want to subscribe to. Additional features could be 514 associated to this subscription phase, like the selection of a level 515 of quality associated to the delivery of the VPN service, the level 516 of management of the VPN service performed by the SP, security 517 options, etc. 519 2.3.2 L3VPN Service Order Management 521 This operation aims at managing the requests initiated by the 522 customers and tracks the status of the achievement of the related 523 operations. The activation of the orders is conditioned by the 524 availability of the resources that meet the customer's requirements 525 with the agreed guarantees (note that could be a result of a 526 negotiation phase between the customer and the provider). 528 2.3.3 L3VPN Service Assurance 530 The customer may require to have the means to evaluate the 531 fulfillment of the contracted SLA with the provider. Thus, the 532 provider should monitor, measure and provide statistical information 533 to the customer assuming an agreement between both parties on the 534 measurement methodology as well as the specification of the 535 corresponding (set of) quality of service indicators. 537 3. Provider Network Manager 539 3.1 Provider Network Management Definition 541 When implementing a VPN architecture within a domain (or a set of 542 domains managed by a single SP), the SP must have a means to view the 543 physical and logical topology of the VPN premises, the VPN 544 operational status, the VPN service ordering status, the VPN service 545 handling, the VPN service activation status, and other aspects 546 associated with each customer's VPN. 548 The management of a VPN service from a provider's perspective 549 consists mainly of: 551 o Managing the customers (the term "customer" denotes a role rather 552 than the end user, thus a SP could be a customer) and end-users in 553 terms of SLA 555 o Managing the VPN premises (especially creating, modifying and 556 deleting operations, editing the related information to a specific 557 link or supervising the AAA [RFC2903] [RFC2906] operations) 559 o Managing the CE-PE links (particularly creating, modifying and 560 deleting links, editing the related information to a specific VPN) 562 o Managing the service ordering like Quality of Service in terms of 563 supported classes of service, traffic isolation, etc. 565 Currently, proprietary methods are often used to manage VPNs. The 566 additional expense associated with operators having to use multiple 567 proprietary configuration- related management methods (e.g., Command 568 Line Interface (CLI) languages) to access such systems is not 569 recommended, because it affects the overall cost of the service 570 (including the exploitation costs), especially when multiple vendor 571 technologies (hence multiple expertise) are used to support the VPN 572 service offering. Therefore, devices should provide standards-based 573 interfaces. From this perspective, additional requirements on 574 possible interoperability issues and availability of such 575 standardized management interfaces need to be investigated. 577 3.2 Network Management Functions 579 In addition, there can be internal service provided by the SP for 580 satisfying the customer service requirements. Some of these may 581 include the notion of dynamic deployment of resources for supporting 582 the customer-visible services, high availability service for the 583 customer may be supported by automatic failure detection and 584 automatic switchover to back-up VPNs. These are accomplished with 585 inter-working with the FCAPS capabilities of Provider Network 586 Manager. 588 3.2.1 Fault Management 590 The Provider Network Manager support for fault management includes: 592 o Fault detection (incidents reports, alarms, failure 593 visualization), 595 o Fault localization (analysis of alarms reports, diagnostics), 597 o Corrective actions (data path, routing, resource allocation). 599 Since L3VPNs rely upon a common network infrastructure, the Provider 600 Network Manager provides a means to inform the Service Manager about 601 the VPN customers impacted by a failure in the infrastructure. The 602 Provider Network Manager should provide pointers to the related 603 customer configuration information to contribute to the procedures of 604 fault isolation and the determination of corrective actions. 606 It is desirable to detect faults caused by configuration errors, 607 because these may cause VPN service to fail, or not meet other 608 requirements (e.g., traffic and routing isolation). One approach 609 could be a protocol that systematically checks that all constraints 610 have been taken into account, and consistency checks have been 611 enforced during the tunnel configuration process. 613 A capability that aims at checking IP reachability within a VPN must 614 be provided for diagnostic purposes. 616 A capability that aims at checking the configuration of a VPN device 617 must be provided for diagnostic purposes. 619 3.2.2 Configuration Management 621 The Provider Network Manager must support configuration management 622 capabilities to deploy VPNs. To do so, a Provider Network Manager 623 must provide configuration management to provision at least the 624 following L3VPN components: PE, CE, hierarchical tunnels, access 625 connections, routing, and QoS, as detailed in this section. If 626 access to the Internet is provided, then this option must also be 627 configurable. 629 Provisioning for adding or removing VPN customer premises should be 630 as automated as possible. 632 Finally, the Provider Network Manager must ensure that these devices 633 and protocols are provisioned consistently and correctly. The 634 solution should provide a means for checking if a service order is 635 correctly provisioned. This would represent one method of diagnosing 636 configuration errors. Configuration errors can arise due to a 637 variety of reasons: manual configuration, intruder attacks, and 638 conflicting service requirements. 640 Requirements for L3VPN configuration management are: 642 o The Provider Network Manager must support configuration of VPN 643 membership 645 o The Provider Network Manager should use identifiers for SPs, 646 L3VPNs, PEs, CEs, hierarchical tunnels and access connections. 648 o Tunnels must be configured between PE/CE devices. This requires 649 coordination of tunnel identifiers, paths, VPNs, and any 650 associated service information, for example, a QoS service. 652 o Routing protocols running between PE routers and CE devices must 653 be configured. For multicast services, multicast routing 654 protocols must also be configurable. 656 o Routing protocols running between PE routers, and between PE and P 657 routers must also be configured. 659 PE-based only: 661 o Routing protocols running between PE routers and CE devices, if 662 any, must be configured on a per-VPN basis. The Provider Network 663 Manager must support configuration of a CE routing protocol for 664 each access connection. 666 o The configuration of a PE-based L3VPN should be coordinated with 667 the configuration of the underlying infrastructure, including 668 Layer 1 and 2 networks interconnecting components of a L3VPN. 670 3.2.2.1 Provisioning Routing-based Configuration Information 672 If there is an IGP running within the L3VPN, the Provider Network 673 Manager must provision the related parameters. This includes 674 metrics, capacity, QoS capability, and restoration parameters. 676 3.2.2.2 Provisioning Access-based Configuration Information 678 The Provider Network Manager must provision network access between 679 SP-managed PE and CE equipment. 681 3.2.2.3 Provisioning Security Services-based Configuration Information 683 When a security service is requested, the Provider Network Manager 684 must provision the entities and associated parameters involved in the 685 provisioning of the service. For example, for IPsec services, 686 tunnels, options, keys, and other parameters should be provisioned at 687 either the CE and/or the PE routers. In the case of an intrusion 688 detection service, the filtering and detection rules should be 689 provisioned on a VPN basis. 691 3.2.2.4 Provisioning VPN Resource Parameters 693 A service provider should have a means to dynamically provision 694 resources associated with VPN services. For example, in a PE-based 695 service, the number and size of virtual switching and forwarding 696 table instances should be provisioned. 698 If a SP supports a "Dynamic Bandwidth Management" service, then the 699 dates, times, amounts and intervals required to perform requested 700 bandwidth allocation change(s) may be traceable for accounting 701 purposes. 703 If a SP supports a "Dynamic Bandwidth Management" service, then the 704 provisioning system must be able to make requested changes within the 705 ranges and bounds specified in the Service Level Specifications. 706 Examples of QoS parameters are the response time and the probability 707 of being able to service such a request. 709 Dynamic VPN resource allocation is crucial to cope with the frequent 710 requests for changes that are expressed by customers (e.g., sites 711 joining or leaving a VPN), as well as to achieve scalability. The PE 712 routers should be able to dynamically assign the VPN resources. This 713 capability is especially important for dial-up and wireless VPN 714 services. 716 3.2.2.5 Provisioning Value-Added Service Access 718 A L3VPN service provides controlled access between a set of sites 719 over a common backbone. However, many service providers also offer a 720 range of value-added services, for example: Internet access, firewall 721 services, intrusion detection, IP telephony and IP Centrex, 722 application hosting, backup, etc. It is outside of the scope of this 723 document to define if and how these different services interact with 724 the VPN service offering. However, the VPN service should be able to 725 provide access to these various types of value-added services. 727 A VPN service should allow the SP to supply the customer with 728 different kinds of well-known IP services (e.g. DNS, NTP, RADIUS, 729 etc.) needed for ordinary network operation and management. The 730 provider should be able to provide IP services to multiple customers 731 from one or many servers. 733 A firewall function may be required to restrict access to the L3VPN 734 from the Internet [Y.1311]. 736 Managed firewalls may be supported on a per-VPN basis, although 737 multiple VPNs will be supported by the same physical device. In such 738 cases, managed firewalls should be provided at the access point(s) of 739 the L3VPN. Such services may be embedded in the CE or PE devices, or 740 implemented in standalone devices. 742 The Provider Network Manager should allow a customer to outsource the 743 management of an IP service to the SP providing the VPN or a third 744 party. 746 The management system should support collection of information 747 necessary for optimal allocation of IP services in response to 748 customers' orders, in correlation with provider- provisioned 749 resources supporting the service. 751 If Internet access is provided, reachability to and from the Internet 752 from/to sites within a VPN should be configurable by an SP. 753 Configuring routing policy to control distribution of VPN routes 754 advertised to the Internet may realize this. 756 3.2.2.6 Provisioning Hybrid VPN Services 758 Configuration of interworking L3VPN solutions should also be 759 supported, taking security and end-to-end QoS issues into account. 761 3.2.3 Accounting 763 The Provider Network Manager is responsible for the measurements of 764 resource utilization. 766 3.2.4 Performance Management 768 From the Provider Network Manager's perspective, performance 769 management includes functions involved in monitoring and collecting 770 performance data regarding devices, facilities, and services. 772 The Provider Network Manager must monitor the devices' behavior to 773 evaluate performance metrics associated with a SLS. Different 774 measurement techniques may be necessary depending on the service for 775 which an SLA is provided. Example services are QoS, security, 776 multicast, and temporary access. These techniques may be either 777 intrusive or non-intrusive, depending on the parameters being 778 monitored. 780 The Provider Network Manager must also monitor aspects of the VPN not 781 directly associated with a SLS, such as resource utilization, status 782 of devices and transmission facilities, as well as control of 783 monitoring resources such as probes and remote agents at network 784 access points used by customers and mobile users. 786 Devices supporting L3VPN whose level of quality is defined by SLSs 787 should have real-time performance measurements that have indicators 788 and threshold crossing alerts. Such thresholds should be 789 configurable. 791 3.2.5 Security Management 793 From the Provider Network Manager's perspective, the security 794 management function of the Provider Network Manager must include 795 management features to guarantee the preservation of the 796 confidentiality of customers' traffic and control data as described 797 in [RFC3809]. 799 3.2.5.1 Authentication Management 801 The Provider Network Manager must support standard methods for 802 authenticating users attempting to access VPN services. 804 Scalability is critical as the number of nomadic/mobile clients is 805 increasing rapidly. The authentication scheme implemented for such 806 deployments must be manageable for large numbers of users and VPN 807 access points. 809 Support for strong authentication schemes needs to be supported to 810 ensure the security of both VPN access point-to-VPN access point (PE 811 to PE) and client-to-VPN Access point (CE-to-PE) communications. 812 This is particularly important to prevent VPN access point (VPN AP) 813 spoofing. VPN Access Point Spoofing is the situation where an 814 attacker tries to convince a PE or a CE that the attacker is the VPN 815 Access Point. If an attacker succeeds, then the device will send VPN 816 traffic to the attacker (who could forward it on to the actual (and 817 granted) access point after compromising confidentiality and/or 818 integrity). 820 In other words, a non-authenticated VPN AP can be spoofed with a man- 821 in-the-middle attack, because the endpoints rarely verify each other. 822 A weakly authenticated VPN AP may be subject to such an attack. 823 However, strongly authenticated VPN APs are not subject to such 824 attacks, because the man-in-the-middle cannot authenticate as the 825 real AP, due to the strong authentication algorithms. 827 4. L3VPN Devices 829 4.1 Information model 831 Each L3VPN solution must specify the management information (MIBs, 832 PIBs, XML schemas, etc.) for network elements involved in L3VPN 833 services. This is an essential requirement in network provisioning. 834 The approach should identify any L3VPN specific information not 835 contained in a standards track MIB module. 837 4.2 Communication 839 The deployment of a VPN may span a wide range of network equipment, 840 potentially including equipment from multiple vendors. Therefore, 841 the provisioning of a unified network management view of the VPN 842 shall be simplified by means of standard management interfaces and 843 models. This will also facilitate customer self-managed (monitored) 844 network devices or systems. 846 In case where significant configuration is required whenever a new 847 service is to be provisioned, it is important for scalability reasons 848 that the NMS provides a largely automated mechanism for the relevant 849 configuration operations. Manual configuration of VPN services 850 (i.e., new sites, or re-provisioning existing ones), could lead to 851 scalability issues, and should be avoided. It is thus important for 852 network operators to maintain visibility of the complete picture of 853 the VPN through the NMS system. This should be achieved by using 854 standards track protocols such as SNMP. Use of proprietary command- 855 line interfaces is not recommended. 857 5. Security Considerations 859 This draft describes a framework for L3PVN Operations and Management. 860 Although this document discusses and addresses some security concerns 861 in Section 2.2.5 and Section 3.2.5 above, it does not introduce any 862 new security concerns. 864 6. Acknowledgments 866 Special Thanks to Nathalie Charton, Alban Couturier, Christian 867 Jacquenet and Harmen Van Der Linde for their review of the document 868 and their valuable suggestions. 870 7. IANA Considerations 872 This document does not contain any IANA considerations. 874 8. Normative References 876 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 877 Accounting Management", RFC 2975, October 2000. 879 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 880 Internet Protocol", RFC 2401, November 1998. 882 [RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and 883 D. Spence, "Generic AAA Architecture", RFC 2903, 884 August 2000. 886 [RFC2906] Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., 887 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 888 D. Spence, "AAA Authorization Requirements", RFC 2906, 889 August 2000. 891 [RFC3809] Nagarajan, A., "Generic Requirements for Provider 892 Provisioned Virtual Private Networks (PPVPN)", RFC 3809, 893 June 2004. 895 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 896 Private Network (VPN) Terminology", RFC 4026, March 2005. 898 [Y.1311] ITU, "Network-based IP VPN over MPLS architecture", ITU- 899 T Y.1311.1, 2001. 901 Authors' Addresses 903 Yacine El Mghazli (Editor) 904 Alcatel 905 Route de Nozay 906 Marcoussis 91460 907 France 909 Email: yacine.el_mghazli@alcatel.fr 910 Thomas D. Nadeau 911 Cisco Systems, Inc. 912 300 Apollo Drive 913 Chelmsford, MA 01824 914 USA 916 Email: tnadeau@cisco.com 918 Mohamed Boucadair 919 France Telecom 920 42, rue des Coutures 921 Caen 14066 922 France 924 Email: mohamed.boucadair@francetelecom.com 926 Kwok Ho Chan 927 Nortel Networks 928 600 Technology Park Drive 929 Billerica, MA 01821 930 USA 932 Email: khchan@nortelnetworks.com 934 Arnaud Gonguet 935 Alcatel 936 Route de Nozay 937 Marcoussis 91460 938 France 940 Email: arnaud.gonguet@alcatel.fr 942 Intellectual Property Statement 944 The IETF takes no position regarding the validity or scope of any 945 Intellectual Property Rights or other rights that might be claimed to 946 pertain to the implementation or use of the technology described in 947 this document or the extent to which any license under such rights 948 might or might not be available; nor does it represent that it has 949 made any independent effort to identify any such rights. Information 950 on the procedures with respect to rights in RFC documents can be 951 found in BCP 78 and BCP 79. 953 Copies of IPR disclosures made to the IETF Secretariat and any 954 assurances of licenses to be made available, or the result of an 955 attempt made to obtain a general license or permission for the use of 956 such proprietary rights by implementers or users of this 957 specification can be obtained from the IETF on-line IPR repository at 958 http://www.ietf.org/ipr. 960 The IETF invites any interested party to bring to its attention any 961 copyrights, patents or patent applications, or other proprietary 962 rights that may cover technology that may be required to implement 963 this standard. Please address the information to the IETF at 964 ietf-ipr@ietf.org. 966 Disclaimer of Validity 968 This document and the information contained herein are provided on an 969 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 970 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 971 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 972 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 973 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 974 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 976 Copyright Statement 978 Copyright (C) The Internet Society (2005). This document is subject 979 to the rights, licenses and restrictions contained in BCP 78, and 980 except as set forth therein, the authors retain all their rights. 982 Acknowledgment 984 Funding for the RFC Editor function is currently provided by the 985 Internet Society.