L3VPN WG                                           Yacine El Mghazli
   Internet Draft                                               Alcatel
   <draft-ietf-l3vpn-mgt-fwk-01.txt>
   Category: Informational                             Thomas D. Nadeau
                                                          Cisco Systems
   Expires: July 2004
                                                           Kwok Ho Chan
                                                        Nortel Networks
  
                                                      Mohamed Boucadair
                                                         France Telecom
  
                                                         Arnaud Gonguet
                                                                Alcatel
  
  
                                                           January 2004
  
  
  
  
               Framework for L3VPN Operations and Management
  
  
  
  
  
  Status of this Memo
  
  
   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026 except that the right to produce derivative
   works is not granted.
  
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.
  
   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".
  
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
  
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
  
  
  
  El Mghazli and al.     Expires - July 2004                 [Page 1]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  Abstract
  
   This document provides a framework for operation and management of
   Layer 3 Virtual Private Networks (L3VPNs). This framework intends to
   produce a coherent description of the significant technical issues
   that are important in the design of L3VPN management solutions.
   Selection of specific approaches, making choices among information
   models and protocols are outside of the scope of this document.
  
  
  Conventions used in this document
  
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as deL3scribed in [RFC2119].
  
  
  Table of Contents
  
   1. Introduction...................................................4
      1.1 Changes since last version.................................4
      1.2 Terminology................................................4
      1.3 Management Functions.......................................5
      1.4 Reference Models...........................................6
   2. PPVPN Service Operations and Management........................8
      2.1 Service Management: Overview...............................8
      2.2 PPVPN Service Offering Management..........................9
      2.3 PPVPN Service Order Management.............................9
      2.4 PPVPN Service Assurance....................................9
      2.5 Customer Service Management Information Model..............9
           2.5.1 SLA/SLS Content....................................10
      2.6 Customer Management Functions.............................10
           2.6.1 Fault Management...................................11
           2.6.2 Configuration Management...........................11
           2.6.3 Accounting.........................................11
           2.6.4 Performance Management.............................12
           2.6.5 Security Management................................12
      2.7 Customer Management Architecture..........................13
           2.7.1 Functional Architecture............................14
           2.7.2 Communication......................................14
   3. L3VPN Provider Network Manager................................14
      3.1 Provider Network Management Definition....................14
      3.2 Network Management Functions..............................15
           3.2.1 Fault Management...................................15
           3.2.2 Configuration Management...........................16
           3.2.3 Accounting.........................................20
           3.2.4 Performance Management.............................20
           3.2.5 Security Management................................20
      3.3 Network Management Information Models.....................20
  
  
  El Mghazli and al.     Expires - July 2004                 [Page 2]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
      3.4 Network Management Architecture...........................21
   4. L3VPN Devices.................................................21
      4.1 Information model.........................................21
           4.1.1 Standard MIBs/PIBs.................................21
           4.1.2 L3VPN specific MIBs/PIBs...........................22
      4.2 Communication.............................................23
   5. Configuration aspects of PPVPN solutions......................23
      5.1 Layer 2 VPNs..............................................23
           5.1.1 VPWS...............................................23
           5.1.2 VPLS...............................................23
      5.2 Layer 3 VPNs..............................................23
           5.2.1 PE-based 2547bis...................................23
           5.2.2 PE-based Virtual Router............................23
           5.2.3 CE-based VPNs using IPSec..........................23
   Security Considerations..........................................23
   References.......................................................24
   Acknowledgments..................................................25
   Authors' Addresses...............................................25
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  El Mghazli and al.     Expires - July 2004                 [Page 3]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  1. Introduction
  
  1.1 Changes since last version
  
     . Add new section 1.2 on terminology.
     . Rewording of major parts of the document.
  
  1.2 Terminology
  
   In this document, the following terms are used and defined as
   follows:
  
   VPN:
      Virtual Private Network. A set of transmission and switching
      resources, which will be used over a public infrastructure to
      process  the  (IP)  traffic  that  characterizes  communication
      services between the sites or premises interconnected via this
      VPN. Such VPN networks MUST provide user identification and
      authorization capabilities so that their access can be granted
      accordingly, and they SHOULD also provide some guarantees as far
      as the preservation of the VPN traffic's confidentiality is
      concerned.
  
   VPN Instance:
      From a management standpoint, a VPN instance is the collection of
      management data that strictly refer to a given VPN that has been
      deployed and managed by a VPN service provider.
  
   VPN Site:
      A VPN customer's location that can access at least one VPN.
  
   VPN Service Provider (SP):
      A Service Provider that offers VPN-related services.
  
   VPN Customer:
      Refers to a customer that bought VPNs from a VPN service provider.
  
   PPVPN:
      Provider  Provisioned  VPN.  Denotes  VPNs  for  which  a  service
      provider participates in provisioning and management.
  
   L3VPN:
      PPVPN for providing layer-3 (routed) services. See [L3VPN-FRWK].
  
   Customer Agent:
      Denotes the entity that is responsible for requesting VPN customer
      specific information.
  
  
  
  
  El Mghazli and al.     Expires - July 2004                 [Page 4]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
   SLA:
      Service Level Agreement.
  
   SLS:
      Service Level Specifications.
  
  
  1.3 Management Functions
  
   For any type of Layer-3 PPVPN (PE or CE-based VPNs) it is recommended
   to have a management platform where the VPN-related information could
   be collected and managed. The Service and Network Management System
   may centralize information related to instances of a VPN and allow
   users to configure and provisions each instance from a central
   location.
  
   A SP must be able to manage the capabilities and characteristics of
   their VPN services. Customers should have means to ensure fulfillment
   of the VPN service they subscribed to. To the extent possible,
   automated operations and interoperability with standard management
   protocols should be supported.
  
   Two main management functions are identified:
  
     . A customer service management function:
  
   Provides the means for a customer to query or configure customer
   specific information, or receive alarms regarding his or her VPN.
   Customer specific information includes data related to contact,
   billing,  site,  access  network,  IP  address,  routing  protocol
   parameters, etc. It may also include confidential data, such as
   encryption keys. Several solutions could be used: (1) proprietary
   network management system (2) SNMP manager (3) PDP function (4)
   directory service, etc. The customer should have a means to order
   VPN-based  services  (we  will  refer  to  this  function  as  "VPN
   Ordering").
  
     . A provider network management function:
  
   This function is responsible for configuring and provisioning the
   network  resources  in  order  to  meet  the  offered  VPN  services
   requirements. This mainly consists of (1) managing, (2) provisioning
   and (3) configuring the physical links, the offered VPNS, the
   subscribed  customers  and  the  VPN  services  offering.  Additional
   features to be supported includes add a VPN, add a customer, delete a
   VPN, modifying VPN-related parameters. In addition, the VPN-SLS
   assurance should be deployed in order to verify the fulfillment of
   the subscribed VPN agreements.
  
  
  
  El Mghazli and al.     Expires - July 2004                 [Page 5]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  
  1.4 Reference Models
  
   The ITU-T Telecommunications Management Network has the following
   generic requirements structure:
  
     . Engineer,  deploy  and  manage  the  switching,  routing  and
        transmission resources supporting the service, from a network
        perspective (network element management);
  
     . Manage  the  VPNs  deployed  over  these  resources  (network
        management);
  
     . Manage the VPN service (service management);
  
  
      - - - - - - - - - - - - - - - - - - - - - - - -:- - - - - - - - -
      Service      +-------------+                   :      +----------+
      Management   |   Service   |<------------------:----->| Customer |
      Layer        |   Manager   |                   :      | Agent    |
                   +-------------+                   :      +----------+
      - - - - - - - - - - ^ - - - - - - - - - - - - -:- - - - - - - - -
      Network             |       +------------+     :
      Management          |       |  Provider  |     :
      Layer               |       |  Network   |  Customer
                          +------>|  Manager   |  Interface
                                  +------------+     :
      - - - - - - - - - - - - - - - - - ^ - - - - - -:- - - - - - - - -
      Network Element                   |            :
      Management                        |  +------+  :  +------+
      Layer                             |  |      |  :  |  CE  |
                                        +->|  PE  |  :  |device|
                                           |device|  :  |  of  |
                                           |      |--:--|VPN  A|
                                           +------+  :  +------+
      ---------------------------------------------->:<----------------
                     SP network                      :  Customer Network
  
            Figure 1: Reference Model for PE-based L3VPNs Management.
  
  
  
  
  
  
  
  
  
  
  
  
  El Mghazli and al.     Expires - July 2004                 [Page 6]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  
      - - - - - - - - - - - - - - - - - - - - - - - -:- - - - - - - - -
      Service      +-------------+                   :      +----------+
      Management   |   Service   |<------------------:----->| Customer |
      Layer        |   Manager   |                   :      | Agent    |
                   +-------------+                   :      +----------+
      - - - - - - - - - - ^ - - - - - - - - - - - - -:- - - - - - - - -
      Network             |       +------------+     :
      Management          |       |  Provider  |     :
      Layer               |       |  Network   |  Customer
                          +------>|  Manager   |  Interface
                                  +------------+     :
      - - - - - - - - - - - - - - - -^- - - -^- - - -:- - - - - - - - -
      Network Element                |       +-------:---------------+
      Management                     |     +------+  :  +------+     |
      Layer                          |     |      |  :  |  CE  |     |
                                     +---->|  PE  |  :  |device|<----+
                                           |device|  :  |  of  |
                                           |      |--:--|VPN  A|
                                           +------+  :  +------+
      ---------------------------------------------->:<----------------
                     SP network                      :  Customer Network
  
            Figure 2: Reference Model for CE-based L3VPNs Management.
  
   Figure 1 and 2 (see above) presents the reference models for both PE
   and  CE-based  L3VPN  management,  according  to  the  aforementioned
   generic structure.
  
   In both models, the service manager administrates customer specific
   attributes, such as customer Identifier (ID), personal information
   (e.g., name, address, phone number, credit card number, etc.),
   subscription  services  and  parameters,  access  control  policy
   information, billing and statistical information, etc.
  
   In  the  PE-based  reference  model,  the  provider  network  manager
   administrates device attributes and their relationship, covering PE
   devices and other devices constructing the corresponding PE-based
   VPN.
  
   In  the  CE-based  reference  model,  the  provider  network  manager
   administrates device attributes and their relationship, covering PE
   *and* CE devices constructing the corresponding CE-based VPN.
  
   Network and customer management systems that are responsible for
   managing VPN networks, have several challenges depending on the type
   of VPN network(s) they are required to manage.
  
  
  
  
  El Mghazli and al.     Expires - July 2004                 [Page 7]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  2. PPVPN Service Operations and Management
  
   The service management groups all functions that aim at managing the
   service-based operations like service ordering, service subscription,
   activation, etc.
  
   The  Customer  Management  function  controls  the  PPVPN  service
   management at the Service Management Layer (SML). It mainly consists
   of defining the PPVPN services offered by the SP, collecting and
   consolidating the customer PPVPN services requirements, as well as
   performing  some  reporting  for  the  customer.  This  function  is
   correlated with the Network Management function at the Network
   Management  Layer  (NML)  for  initiating  the  PPVPN  services
   provisioning, and getting some service reporting.
  
  
  2.1 Service Management: Overview
  
          + - - - - - - - - - - - - - - - - - - - - - - - - -  +
          | Service    +----------------+   +----------------+ |
          | Management |   VPN  Offering|   | VPN Order      | |
          |            |   Management   |   |    Management  | |
          |            +----------------+   +----------------+ |
          |            +----------------+   +----------------+ |
          |            |   VPN          |   | VPN-based      | |
          |            |   Assurance    |   | SLS Management | |
          |            +----------------+   +----------------+ |
          + - - - - - - - - - - - - - - - - - - - - - - - - -  +
  
               Figure 3: Overview of the Service Management
  
   A customer must have a means to view the topology, operational state,
   order status, and other parameters associated with the VPN service
   offering that has been subscribed.
  
   All aspects of management information about CE devices and customer
   attributes of a PPVPN manageable by a SP should be capable of being
   configured and maintained by an authenticated, authorized Service
   manager.
  
   A customer agent should be able to make dynamic requests for changing
   parameters describing a service. A customer should be able to receive
   response from the SP network in response to these requests (modulo
   the existence of necessary agreements). Communication between
   customer Agents and (VPN) service providers will rely upon a
   query/response mechanism.
  
  
  
  El Mghazli and al.     Expires - July 2004                 [Page 8]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
   A customer who may not be able to afford the resources to manage its
   CPE premises should be able to outsource the management of the VPN to
   the service provider(s) supporting the network.
  
  
  2.2 PPVPN Service Offering Management
  
   The deployment of a VPN hopefully addresses customers' requirements.
   Thus, the provider must have the means to advertise the VPN-based
   services it offers. Then, the potential customers could select the
   service they want to subscribe to. Additional features could be
   associated to this subscription phase, like the selection of a level
   of quality associated to the delivery of the VPN service, the level
   of management of the VPN service performed by the SP, security
   options, etc.
  
  
  2.3 PPVPN Service Order Management
  
   This operation aims at managing the requests initiated by the
   customers and tracks the status of the achievement of the related
   operations. The activation of the orders is conditioned by the
   availability of the resources that meet the customer's requirements
   with the agreed guaranties (note that could be a result of a
   negotiation phase between the customer and the provider).
  
  
  2.4 PPVPN Service Assurance
  
   The customer must have the means to evaluate the fulfillment of the
   contracted SLA with the provider. Thus, the provider must monitor,
   measure and provide some statistical information to the customer
   assuming  an  agreement  between  both  parties  on  the  measurement
   methodology as well as the specification of the corresponding (set
   of) quality of service indicators.
  
  
  2.5 Customer Service Management Information Model
  
   This section presents the information model that is used for PPVPN
   service management at the SML. The information models represent the
   data that need to be managed, and the way they are represented. At
   the SML, the information model that is foreseen is composed of
   Service Level Agreements (SLA) and Service Level Specifications
   (SLS).
  
  
  
  
  
  
  El Mghazli and al.     Expires - July 2004                 [Page 9]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
     2.5.1 SLA/SLS Content
  
   Services are described through Service Level Agreements (SLA) that
   are contractual documents between customers and service providers.
   The technical part of the service description is called the Service
   Level  Specification  (SLS).  The  SLS  groups  different  kinds  of
   parameters. Some are more related with the description of the
   transport of the packets, and some with the specification of the
   service itself.
  
   A Service Level Specification (SLS) may be defined per access network
   connection, per VPN, per VPN site, and/or per VPN route. The service
   provider may define objectives and the measurement intervals for at
   least the SLS using the following Service Level Objective (SLO)
   parameters:
  
     . QoS and traffic parameters
     . Availability for the site, VPN, or access connection
     . Duration of outage intervals per site, route or VPN
     . Service activation interval (e.g., time to turn up a new site)
     . Trouble report response time interval
     . Time to repair interval
     . Total incoming/outgoing traffic from a site, a (VPN) route or
        that has transited through the whole VPN
     . Measurement of non-conforming incoming/outgoing traffic
        (compliance of traffic should deserve some elaboration, because
        of many perspectives - security, QoS, routing, etc.) from a
        site, a (VPN) route, or which has transited through the whole
        VPN
  
   The service provider and the customer may negotiate contractual
   penalties in the case(s) where the provider does not meet a (set of)
   SLS performance objective(s).
  
   Traffic parameters and actions should be defined for incoming and
   outgoing packets that go through the demarcation between the service
   provider premises and the customer's premises. For example, traffic
   policing functions may be activated at the ingress of the service
   provider's network, while traffic shaping capabilities could be
   activated at the egress of the service provider's network.
  
  
  2.6 Customer Management Functions
  
   This section presents detailed customer management functions in the
   traditional  fault,  configuration,  accounting,  performance,  and
   security (FCAPS) management categories.
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 10]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  
  
     2.6.1 Fault Management
  
   Basically the fault management function of the Customer Service
   Manager  relies  upon  the  manipulation  of  network  layer  failure
   information, and it reports incidents to the impacted customers. Such
   reports should be based upon and relate to the VPN service offering
   subscribed by the customer. The Customer Management function support
   for fault management includes:
  
     . Indication of customer's services impacted by failure,
     . Incident recording or logs.
  
  
  
     2.6.2 Configuration Management
  
   The configuration management function of the Customer Manager must be
   able to configure PPVPN service parameters with the level of detail
   that the customer is able to specify, according to service templates
   defined by the provider.
  
   A service template contains fields which, when instantiated, yield a
   definite service requirement or policy. For example, a template for
   an IPSec tunnel [IPSEC] would contain fields such as tunnel end
   points,   authentication   modes,   encryption   and   authentication
   algorithms, shared keys (if any), and traffic filters.
  
   A BGP/MPLS-based VPN service template would contain fields such as
   the customer premises that need to be interconnected via the VPN.
   A QoS agreement template would contain fields such as one-way transit
   delay, inter-packet delay variation, throughput, and packet loss
   thresholds.
  
  
  
     2.6.3 Accounting
  
   Basically, the accounting management function of the Customer Manager
   is provided with network layer measurements information and manages
   this information. The Customer Manager is responsible for the
   following accounting functions:
  
     . Retrieval of accounting information from the Provider Network
        Manager,
     . Analysis, storage and administration of measurements.
  
  
  El Mghazli and al.     Expires - July 2004                [Page 11]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  
   Some providers may require near-real time reporting of measurement
   information, and may offer this as part of a customer network
   management service.
  
   If a SP supports "Dynamic Bandwidth Management" service, then the
   schedule and the amount of the bandwidth required to perform
   requested bandwidth allocation change(s) must be traceable for
   monitoring and accounting purposes.
  
   Solutions should state compliance with accounting requirements, as
   described in section 1.7 of [RFC2975].
  
  
  
     2.6.4 Performance Management
  
   >From the Customer Manager's perspective, performance management
   includes functions involved in the determination of the conformance
   level  with  the  Service  Level  Specifications,  such  as  QoS  and
   availability measurements. The objective is to correlate accounting
   information with performance and fault management information to
   produce billing that takes into account SLA provisions for periods of
   time where the service level objectives are not met.
  
   The  performance  information  should  reflect  the  quality  of  the
   subscribed VPN service as perceived by the customer. This information
   could be measured by the provider or controlled by a third party. The
   parameters that will be used to reflect the performance level could
   be negotiated and agreed between the service provider and the
   customer during the VPN service negotiation phase.
  
   Performance management should also support analysis of important
   aspects of a PPVPN, such as bandwidth utilization, response time,
   availability, QoS statistics, and trends based on collected data.
  
  
  
     2.6.5 Security Management
  
   From the Customer Manager's perspective, the security management
   function includes management features to guarantee the security of
   devices, configuration data and access connections.
  
  
  
  
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 12]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
      2.6.5.1   Management Access Control
  
   Management access control determines the privileges that a user has
   for particular applications and parts of the network. Without such
   control, only the security of the data and control traffic is
   protected,  leaving  the  devices  providing  the  PPVPN  network
   unprotected, among other equipment or resources. Access control
   capabilities protect these devices to ensure that users have access
   to the sole resources and applications they are granted to use.
  
  
  
      2.6.5.2   Authentication
  
   Authentication is the process of verifying the identity of a VPN
   user.  The  Service  Manager  must  support  standard  methods  for
   authenticating users attempting to access VPN services.
  
   Scalability is critical as the number of nomadic/mobile clients is
   increasing rapidly. The authentication scheme implemented for such
   deployments must be manageable for large numbers of users and VPN
   access points.
  
   Support for strong authentication schemes shall be supported to
   ensure the security of both VPN access point-to-VPN access point (PE
   to PE) and client-to-VPN Access point (CE-to-PE) communications. This
   is particularly important to prevent VPN access point (VPN AP)
   spoofing. VPN Access Point Spoofing is the situation where an
   attacker tries to convince a PE or a CE that the attacker is the VPN
   Access Point. If an attacker succeeds, then the device will send VPN
   traffic to the attacker (who could forward it on to the actual (and
   granted)  access  point  after  compromising  confidentiality  and/or
   integrity).
  
   In other words, a non-authenticated VPN AP can be spoofed with a man-
   in-the-middle attack, because the endpoints rarely verify each other.
   A weakly authenticated VPN AP may be subject to such an attack.
   However, strongly authenticated VPN APs are not subject to such
   attacks, because the man-in-the-middle cannot authenticate as the
   real AP, due to the strong authentication algorithms.
  
  
  2.7 Customer Management Architecture
  
   This section proposes a high level architecture for the PPVPN
   management framework as far as the SML layer is concerned. The goal
   is to map the customer management functions described in section 2.3
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 13]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
   to  architectural  yet  functional  blocks,  and  to  describe  the
   communication with the other PPVPN management functions.
  
  
     2.7.1 Functional Architecture
  
   Two main functional blocks can be recognized:
  
     . A PPVPN Service Manager, for defining the PPVPN services and
        initiating the corresponding provisioning. This block takes the
        Customer Agent requirements as inputs, and the Provider Network
        Management provisioning system as the output.
  
     . A  PPVPN  Service  Assurance  Manager,  for  managing  services
        failures, and performing customer reporting. This block takes
        the Provider Network Management assurance system as an input,
        and the Customer Agent as the output.
  
  
  
     2.7.2 Communication
  
  
      2.7.2.1   Customer Agent interface
  
   TBD
  
  
  
      2.7.2.2   Provider Network Management interface
  
   TBD
  
  
  3. L3VPN Provider Network Manager
  
  3.1 Provider Network Management Definition
  
  
   When implementing a VPN architecture within a domain (or a set of
   domains managed by a single ISP), an ISP must have a means to view
   the physical and logical topology of the VPN premises, the VPN
   operational status, the VPN service ordering status, the VPN service
   handling, the VPN service activation status, and other aspects
   associated with each customer's VPN in terms of set of relevant
   parameters and attributes.
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 14]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  
   The management of a VPN service from a provider's perspective
   consists mainly in:
     . Managing the customers (the term "customer" denotes a role
        rather than the end user, thus a SP could be a customer) and
        end-users in terms of SLA
     . Managing the VPN premises (especially creating, modifying and
        deleting operations, editing the related information to a
        specific link or supervising the AAA [RFC2903][RFC2906]
        operations)
     . Managing the CE-PE links (particularly creating, modifying and
        deleting links, editing the related information to a specific
        VPN)
     . Managing the service ordering like Quality of Service in terms
        of supported classes of service, traffic isolation, etc.
  
   Currently, proprietary methods are often used to manage VPNs. The
   additional expense associated with operators having to use multiple
   proprietary configuration-related management methods (e.g., Command
   Line Interface (CLI) languages) to access such systems is not
   recommended, because it affects the overall cost of the service
   (including the exploitation costs), especially when multiple vendor
   technologies (hence multiple expertise) are used to support the VPN
   service offering. Therefore, devices should provide standards-based
   interfaces  wherever  feasible.  From  this  perspective,  additional
   requirements on possible interoperability issues and availability of
   such standardized management interfaces need to be investigated.
  
  
  3.2 Network Management Functions
  
   In addition, there can be internal service provided by the SP for
   satisfying the customer service requirements. Some of these may
   include the notion of dynamic deployment of resources for supporting
   the customer visible services, high availability service for the
   customer  may  be  supported  by  automatic  failure  detection  and
   automatic switchover to back-up VPNs. These are accomplished with
   inter-working  with  the  FCAPS  capabilities  of  Provider  Network
   Manager.
  
  
  
     3.2.1 Fault Management
  
   The Provider Network Manager support for fault management includes:
  
     . Fault detection (incidents reports, alarms, failure
        visualization),
  
  
  El Mghazli and al.     Expires - July 2004                [Page 15]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
     . Fault localization (analysis of alarms reports, diagnostics),
     . Corrective actions (data path, routing, resource allocation).
  
   Since L3VPNs rely upon a common network infrastructure, the Provider
   Network Manager provides a means to inform the Service Manager about
   the VPN customers impacted by a failure in the infrastructure. The
   Provider Network Manager should provide pointers to the related
   customer configuration information to contribute to the procedures of
   fault isolation and the determination of corrective actions.
  
   It is desirable to detect faults caused by configuration errors,
   because these may cause VPN service to fail, or not meet other
   requirements (e.g., traffic and routing isolation). One approach
   could be a protocol that systematically checks all constraints have
   been taken into account, and consistency checks have been enforced
   during the tunnel configuration process.
  
   A capability that aims at checking IP reachability within a VPN must
   be provided for diagnostic purposes.
  
   A capability that aims at checking the configuration of a VPN device
   must be provided for diagnostic purposes.
  
  
  
     3.2.2 Configuration Management
  
   The Provider Network Manager must support configuration management
   capabilities to deploy VPNs. To do so, a Provider Network Manager
   must provide configuration management to provision at least the
   following L3VPN components: PE, CE, hierarchical tunnels, access
   connections, routing, and QoS, as detailed in this section. If access
   to the Internet is provided, then this option must also be
   configurable.
  
   Provisioning for adding or removing VPN customer premises should be
   as automated as possible.
  
   Finally, the Provider Network Manager must ensure that these devices
   and protocols are provisioned consistently and correctly. The
   solution should provide a means for checking if a service order is
   correctly provisioned. This would represent one method of diagnosing
   configuration errors. Configuration errors can arise due to a variety
   of reasons: manual configuration, intruder attacks, and conflicting
   service requirements.
  
   Requirements for L3VPN configuration management are:
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 16]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
     . The Provider Network Manager must support configuration of VPN
        membership
  
     . The Provider Network Manager should use identifiers for SPs,
        L3VPNs, PEs, CEs, hierarchical tunnels and access connections as
        described in [L3VPN-FRWK].
  
     . Tunnels must be configured between PE/CE devices. This requires
        coordination of tunnel identifiers, hierarchical tunnels, VPNs,
        and any associated service information, for example, a QoS
        service.
  
     . Routing protocols running between PE routers and CE devices must
        be configured. For multicast services, multicast routing
        protocols must also be configurable.
  
     . Routing protocols running between PE routers, and between PE and
        P routers must also be configured.
  
   PE-based only:
  
     . Routing protocols running between PE routers and CE devices must
        be configured on a per VPN basis. The Provider Network Manager
        must support configuration of CE routing protocol for each
        access connection.
  
     . The configuration of a PE-based L3VPN must be coordinated with
        the configuration of the underlying infrastructure, including
        Layer 1 and 2 networks interconnecting components of a L3VPN.
  
  
  
      3.2.2.1   Provisioning Routing-based Configuration Information
  
   The Provider Network Manager must provision parameters for the IGP
   for a L3VPN. This includes metrics, capacity, QoS capability, and
   restoration parameters.
  
  
  
      3.2.2.2   Provisioning Network Access-based Configuration Information
  
   The Provider Network Manager must provision network access between
   SP-managed PE and CE equipments.
  
  
  
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 17]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
      3.2.2.3   Provisioning Security Services-based Configuration Information
  
   When a security service is requested, the Provider Network Manager
   must provision the entities and associated parameters involved in the
   provisioning of the service. For example, for IPSec services,
   tunnels, options, keys, and other parameters must be provisioned at
   either the CE and/or the PE routers. In the case of an intrusion
   detection service, the filtering and detection rules must be
   provisioned on a VPN basis.
  
  
  
      3.2.2.4   Provisioning VPN Resource Parameters
  
   A service provider must have a means to dynamically provision
   resources associated with VPN services. For example, in a PE-based
   service, the number and size of virtual switching and forwarding
   table instances must be provisioned.
  
   Dynamic VPN resource allocation is crucial to cope with the frequent
   requests for changes that are expressed by customers (e.g., sites
   joining or leaving a VPN), as well as to achieve scalability. The PE
   routers should be able to dynamically assign the VPN resources. This
   capability is especially important for dial-up and wireless VPN
   services.
  
   If a SP supports a "Dynamic Bandwidth Management" service, then the
   dates, times, amounts and intervals required to perform requested
   bandwidth allocation change(s) must be traceable for accounting
   purposes.
  
   If a SP supports a "Dynamic Bandwidth Management" service, then the
   provisioning system must be able to make requested changes within the
   ranges and bounds specified in the Service Level Specifications.
   Examples of QoS parameters are the response time and the probability
   of being able to service such a request.
  
  
  
      3.2.2.5   Provisioning Value-Added Service Access
  
   A L3VPN service provides controlled access between a set of sites
   over a common backbone. However, many service providers also offer a
   range of value-added services, for example: Internet access, firewall
   services, intrusion detection, IP telephony and IP Centrex,
   application hosting, backup, etc. It is outside of the scope of this
   document to define if and how these different services interact with
  
  
  El Mghazli and al.     Expires - July 2004                [Page 18]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
   the VPN service offering. However, the VPN service must be able to
   provide access to these various types of value-added services.
  
   A VPN service should allow the SP to supply the customer with
   different kinds of well-known IP services (e.g. DNS, NTP, RADIUS,
   etc.) needed for ordinary network operation and management. The
   provider should be able to provide IP services to multiple customers
   from one or many servers.
  
   A firewall function may be required to restrict access to the L3VPN
   from the Internet [Y.1311].
  
   A managed firewall service must be carrier-class. For redundancy and
   failure recovery purposes, a means for firewall fail-over should be
   provided. Managed firewall services that may be provided include
   dropping specified protocol types, intrusion protection, traffic-rate
   limiting against malicious attacks, etc.
  
   Managed firewalls must be supported on a per-VPN basis, although
   multiple VPNs will be supported by the same physical device. Managed
   firewalls should be provided at the access point(s) of the L3VPN.
   Such services may be embedded in the CE or PE devices, or implemented
   in standalone devices.
  
   The Provider Network Manager should allow a customer to outsource the
   management of an IP service to the SP providing the VPN or a third
   party.
  
   The management system should support collection of information
   necessary for optimal allocation of IP services in response to
   customers' orders, in correlation with provider-provisioned resources
   supporting the service.
  
   Reachability to and from the Internet from/to sites within a VPN must
   be configurable by an SP. Configuring routing policy to control
   distribution of VPN routes advertised to the Internet could realize
   this.
  
  
  
      3.2.2.6   Provisioning Hybrid VPN Services
  
   Configuration of inter-working L3VPN solutions should also be
   supported. Ensuring that security and end-to-end QoS issues are
   addressed.
  
  
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 19]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
     3.2.3 Accounting
  
   The Provider Network Manager is responsible for the measurements of
   resource utilization.
  
  
  
     3.2.4 Performance Management
  
   From the Provider Network Manager's perspective, performance
   management includes functions involved in monitoring and collecting
   performance data regarding devices, facilities, and services.
  
   The Provider Network Manager must monitor the devices' behavior to
   evaluate performance metrics associated with a SLS. Different
   measurement techniques may be necessary depending on the service for
   which an SLA is provided. Example services are QoS, security,
   multicast, and temporary access. These techniques may be either
   intrusive or non-intrusive, depending on the parameters being
   monitored.
  
   The Provider Network Manager must also monitor aspects of the VPN not
   directly associated with a SLS, such as resource utilization, status
   of devices and transmission facilities, as well as control of
   monitoring resources such as probes and remote agents at network
   access points used by customers and mobile users.
  
   Devices supporting L3VPN whose level of quality is defined by SLSs
   should have real-time performance measurements that have indicators
   and threshold crossing alerts. Such thresholds should be
   configurable.
  
  
  
     3.2.5 Security Management
  
   From the Provider Network Manager's perspective, the security
   management function of the Provider Network Manager must include
   management features to guarantee the preservation of the
   confidentiality of customers' traffic and control data as described
   in section 5.9 of [L3VPN-REQ].
  
  
  3.3 Network Management Information Models
  
   TBD
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 20]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  
  3.4 Network Management Architecture
  
   TBD
  
  
  4. L3VPN Devices
  
  4.1 Information model
  
   Each L3VPN solution must specify the information bases (MIBs, PIBs,
   XML schemas, etc.) for network elements involved in L3VPN services.
   This is an essential requirement in network provisioning. The
   approach should identify any L3VPN specific information not contained
   in a standard MIB.
  
  
  
     4.1.1 Standard MIBs/PIBs
  
      4.1.1.1   Customer visible routing
  
   According to section 3.3 of [L3VPN-FRWK], the following technologies
   are available for the exchange of routing information at the customer
   interface level. The corresponding MIBs can be used for managing
   routing policies across the customer interface.
  
     . Static routing
     . RIP (Routing Information Protocol)
     . OSPF (Open Shortest Path First)
     . BGP-4 (Border Gateway Protocol version 4)
  
  
  
      4.1.1.2   Routing across the SP backbone
  
   According to section 4.4 of [L3VPN-FRWK], the following technologies
   are available for routing within the SP network:
  
     . Per-VPN routing model
          o Static routing
          o RIP
          o OSPF
          o IS-IS
          o BGP-4
  
     . Aggregated routing model
  
  
  El Mghazli and al.     Expires - July 2004                [Page 21]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
          o MP-iBGP [MP-BGP4]
          o OSPF
          o IS-IS
  
  
  
      4.1.1.3   VPN tunneling
  
   According to section 4.4 of [L3VPN-FRWK], the following technologies
   are available for VPN tunneling within the SP network:
  
     . MPLS
     . GRE
     . IPSec ([IPSEC-MIB], [IPSEC-PIB])
     . IP-in-IP
  
  
  
      4.1.1.4   Quality of Service
  
   According to section 4.5 of [L3VPN-FRWK], the following technologies
   are available for QoS support within the SP network:
  
     . Diffserv ([RFC3289], [RFC3317])
     . RSVP signaling
  
  
  
     4.1.2 L3VPN specific MIBs/PIBs
  
      4.1.2.1   PE-based L3VPN
  
     . Layer 3 VPNs
          o BGP/MPLS VPNs ([MIB-2547], [PIB-2547])
          o Virtual Routers ([VR-MIB])
          o TBD
  
     . Layer 2 VPNs:
          o TBD
  
  
      4.1.2.2   CE-based L3VPN
  
     . TBD
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 22]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  
  4.2 Communication
  
   The deployment of a VPN may span a wide range of network equipment,
   potentially including equipment from multiple vendors. Therefore, the
   provisioning of a unified network management view of the VPN shall be
   simplified by means of standard management interfaces and models.
   This will also facilitate customer self-managed (monitored) network
   devices or systems.
  
   In case where significant configuration is required whenever a new
   service is to be provisioned, it is important for scalability reasons
   that the NMS provides a largely automated mechanism for the relevant
   configuration operations.
   Manual configuration of VPN services (i.e., new sites, or re-
   provisioning existing ones), could lead to scalability issues, and
   should be avoided. It is thus important for network operators to
   maintain visibility of the complete picture of the VPN through the
   NMS system. This should be achieved by using standard protocols such
   as SNMP, COPS, NetConf. Use of proprietary command-line interfaces is
   not recommended.
  
  
  5. Configuration aspects of PPVPN solutions
  
  5.1 Layer 2 VPNs
  
     5.1.1 VPWS
  
     5.1.15.1.2 VPLS
  
  5.2 Layer 3 VPNs
  
     5.2.1 PE-based 2547bis
  
     5.2.15.2.2 PE-based Virtual Router
  
     5.2.15.2.3 CE-based VPNs using IPSec
  
  Security Considerations
  
   TBD
  
  
  
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 23]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  References
  
   [L3VPN-REQ] M. Carugi, D. McDysan, L. Fang, F. Johansson, Ananth
      Nagarajan, J. Sumimoto, R. Wilder, 'Service requirements for Layer
      3 Provider Provisioned Virtual Private', draft-ietf-l3vpn-
      requirements-00.txt , March 2002.
  
   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997.
  
   [L3VPN-FRWK] R. Callon, M. Suzuki, J. De Clercq, B. Gleeson, A.
      Malis, K. Muthukrishnan, E. Rosen, C. Sargor, J. Yu, 'A Framework
      for Layer 3 Provider Provisioned Virtual Private Networks', draft-
      ietf-l3vpn-framework-00.txt>, April 2002.
  
   [RFC2096] F. Baker, 'IP Forwarding Table MIB', RFC2096, January 1997.
  
   [MP-BGP4] D Katz, Yakov Rekhter, T. Bates, R.Chandra, 'Multiprotocol
      Extensions for BGP-4', RFC2858, June 2000.
  
   [IPSEC-PIB] Avri Doria, David Arneson, Jamie Jason, Cliff Wang,
      Markus Stenberg, Man Li, 'IPSec Policy Information Base', draft-
      ietf-ipsp-ipsecpib-09.txt, February 2002.
  
   [RFC3289] F. Baker, K. Chan, A. Smith, 'Management Information Base
      for the Differentiated Services Architecture', RFC3289, May2002.
  
   [RFC3317] K. McCloghrie, K. Chan, R. Sahita, S. Hahn, 'Differentiated
      Services Quality of Service Policy Information Base', RFC3317,
      March 2003.
  
   [MIB-2547] Thomas Nadeau, 'MPLS/BGP Virtual Private Network
      Management Information Base UsingSMIv2', draft-ietf-l3vpn-mpls-
      vpn-mib-00.txt, May 2002.
  
   [PIB-2547] Yacine El Mghazli, 'BGP/MPLS VPN Policy Information Base',
      draft-yacine-ppvpn-2547bis-pib-02.txt, February 2003.
  
   [Y.1311.1] Carugi M., "Network Based IP VPN over MPLS
      architecture",Y.1311.1 ITU-T Recommendation, May 2001.
  
   [IPSEC] S. Kent et al., "Security Architecture for the Internet
      Protocol", RFC 2401, November 1998.
  
   [RFC 2975] B. Aboba et al, "Introduction to Accounting Management",
      October 2000.
  
  
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 24]


  Internet Draft   draft-ietf-l3vpn-mgt-fwk-01.txt       January 2004
  
  
  Acknowledgments
  
   Special Thanks to Nathalie Charton, Alban Couturier and Christian
   Jacquenet for their valuable comments.
  
  
  Authors' Addresses
  
   Yacine El Mghazli (Editor)
   Alcatel
   Route de Nozay
   91460 Marcoussis cedex - FRANCE
   Phone: +33 1 69 63 41 87
   Email: yacine.el_mghazli@alcatel.fr
  
   Thomas D. Nadeau
   Cisco Systems, Inc.
   300 Apollo Drive
   Chelmsford, MA 01824 - USA
   Phone: +1 978 497 3051
   Email: tnadeau@cisco.com
  
   Kwok Ho Chan
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA 01821 - USA
   Phone: +1 978 288 8175
   Email: khchan@nortelnetworks.com
  
   Mohamed Boucadair
   France Telecom
   42, rue des Coutures
   BP 6243
   14066 Caen Cedex 4 - FRANCE
   Phone: +33 2 31 75 92 31
   Email: mohamed.boucadair@francetelecom.com
  
   Arnaud Gonguet
   Alcatel
   Route de Nozay
   91460 Marcoussis cedex - FRANCE
   Phone: +33 1 69 63 42 17
   Email: arnaud.gonguet@alcatel.fr
  
  
  
  
  
  
  
  
  El Mghazli and al.     Expires - July 2004                [Page 25]