Internet DRAFT - draft-ietf-l3vpn-requirements

draft-ietf-l3vpn-requirements



   INTERNET DRAFT                                             M. Carugi 
   Internet Engineering Task Force                      Nortel Networks 
   Document:                                                 D. McDysan 
   draft-ietf-l3vpn-requirements-02.txt                             MCI 
   July 2004                                               (Co-Editors) 
   Category: Informational                                              
   Expires: January 2005                                                
    
   Service requirements for Layer 3 Virtual Private Networks:    
   <draft-ietf-l3vpn-requirements-02.txt> 
    
   Status of this memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC 2026 ([RFC-2026]). 
    
   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. 
    
   This document is a product of the IETF's Layer 3 Virtual Private 
   Network (l3vpn) working group. Comments should be addressed to WG's 
   mailing list at l3vpn@ietf.org. The charter for l3vpn may be found 
   at http://www.ietf.org/html.charters/l3vpn-charter.html 
    
   Copyright (C) The Internet Society (2000). All Rights Reserved. 
   Distribution of this memo is unlimited. 
    
   Abstract 
    
   This document provides requirements for Layer 3 Virtual Private 
   Networks (L3VPNs). It identifies requirements applicable to a number 
   of individual approaches that a Service Provider may use for the 
   provisioning of a VPN service. This document expresses a service 
   provider perspective, based upon past experience of IP-based service 
   offerings and the ever-evolving needs of the customers of such 
   services. Toward this end, it first defines terminology and states 
   general requirements. Detailed requirements are expressed from a 
   customer as well as a service provider perspective. 
    
    
    
   Carugi, McDysan et al                                            1 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   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 described in RFC 2119 ([RFC-
   2119]). 
    
   Table of Contents 
   1 Introduction....................................................5 
 1.1  Scope of this document.........................................5 
 1.2  Outline........................................................6 
   2 Contributing Authors............................................6 
   3 Definitions.....................................................6 
 3.1  Virtual Private Network........................................6 
 3.2  Users, Sites, Customers and Agents.............................7 
 3.3  Intranets, Extranets, and VPNs.................................7 
 3.4  Networks of Customer and Provider Devices......................7 
 3.5  Access Networks, Tunnels, and Hierarchical Tunnels.............8 
 3.6  Use of Tunnels and roles of CE and PE in L3 VPNs...............9 
   3.6.1   PE-Based Layer 3 VPNs and Virtual Forwarding Instances....9 
   3.6.2   CE-Based L3VPN Tunnel Endpoints and Functions............10 
 3.7  Customer and Provider Network Management......................11 
   4 Service Requirements Common to Customers and Service Providers.12 
 4.1  Isolated Exchange of Data and Routing Information.............12 
 4.2  Addressing....................................................12 
 4.3  Quality of Service............................................12 
   4.3.1   QoS Standards............................................13 
   4.3.2   Service Models...........................................14 
 4.4  Service Level Specification and Agreements....................14 
 4.5  Management....................................................15 
 4.6  Interworking..................................................15 
   5 Customer Requirements..........................................15 
 5.1  VPN Membership (Intranet/Extranet)............................15 
 5.2  Service Provider Independence.................................16 
 5.3  Addressing....................................................16 
 5.4  Routing Protocol Support......................................16 
 5.5  Quality of Service and Traffic Parameters.....................16 
   5.5.1   Application Level QoS Objectives.........................16 
   5.5.2   DSCP Transparency........................................17 
 5.6  Service Level Specification/Agreement.........................17 
 5.7  Customer Management of a VPN..................................18 
 5.8  Isolation.....................................................18 
 5.9  Security......................................................18 
 5.10 Migration Impact..............................................19 
 5.11 Network Access................................................19 
   5.11.1  Physical/Link Layer Technology...........................19 
   5.11.2  Temporary Access.........................................19 
   5.11.3  Sharing of the Access Network............................20 
   5.11.4  Access Connectivity......................................20 
 5.12 Service Access................................................22 
   5.12.1  Internet Access..........................................22 
   5.12.2  Hosting, Application Service Provider....................22 
    
   Carugi, McDysan et al Informational - Expires January 2005       2 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   5.12.3  Other Services...........................................22 
 5.13 Hybrid VPN Service Scenarios..................................22 
   6 Service Provider Network Requirements..........................23 
 6.1  Scalability...................................................23 
 6.2  Addressing....................................................23 
 6.3  Identifiers...................................................23 
 6.4  Discovering VPN Related Information...........................24 
 6.5  SLA and SLS Support...........................................24 
 6.6  Quality of Service (QoS) and Traffic Engineering..............25 
 6.7  Routing.......................................................25 
 6.8  Isolation of Traffic and Routing..............................26 
 6.9  Security......................................................26 
   6.9.1   Support for Securing Customer Flows......................26 
   6.9.2   Authentication Services..................................27 
   6.9.3   Resource Protection......................................27 
 6.10 Inter-AS (SP)VPNs.............................................28 
   6.10.1  Routing Protocols........................................28 
   6.10.2  Management...............................................28 
   6.10.3  Bandwidth and QoS Brokering..............................29 
   6.10.4  Security Considerations..................................29 
 6.11 L3VPN Wholesale...............................................29 
 6.12 Tunneling Requirements........................................30 
 6.13 Support for Access and Backbone Technologies..................30 
   6.13.1  Dedicated Access Networks................................31 
   6.13.2  On-Demand Access Networks................................31 
   6.13.3  Backbone Networks........................................31 
 6.14 Protection, Restoration.......................................31 
 6.15 Interoperability..............................................32 
 6.16 Migration Support.............................................32 
   7 Service Provider Management Requirements.......................33 
 7.1  Fault management..............................................33 
 7.2  Configuration Management......................................34 
   7.2.1   Configuration Management for PE-Based VPNs...............35 
   7.2.2   Configuration management for CE-based VPN................35 
   7.2.3   Provisioning Routing.....................................35 
   7.2.4   Provisioning Network Access..............................35 
   7.2.5   Provisioning Security Services...........................36 
   7.2.6   Provisioning VPN Resource Parameters.....................36 
   7.2.7   Provisioning Value-Added Service Access..................36 
   7.2.8   Provisioning Hybrid VPN Services.........................37 
 7.3  Accounting....................................................37 
 7.4  Performance Management........................................38 
   7.4.1   Performance Monitoring...................................38 
   7.4.2   SLA and QoS management features..........................38 
 7.5  Security Management...........................................38 
   7.5.1   Resource Access Control....................................38 
   7.5.2   Authentication...........................................39 
 7.6  Network Management Techniques.................................39 
   8 Security Considerations........................................40 
   9 Acknowledgements...............................................40 
   10 References.....................................................41 
 10.1 Normative References..........................................41 
    
   Carugi, McDysan et al Informational - Expires January 2005       3 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
 10.2 Non-normative References......................................41 
   11 Authors' address...............................................43 



















































    
   Carugi, McDysan et al Informational - Expires January 2005       4 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
    
   1 Introduction 
   This section describes the scope and outline of the document. 
    
   1.1 Scope of this document 
   This document provides requirements specific to Layer 3 Virtual 
   Private Networks (L3VPN) (requirements that are generic to L2 and L3 
   VPNs are contained in [PPVPN-GR]).  
   This document identifies requirements that may apply to one or more 
   individual approaches that a Service Provider may use for the 
   provisioning of a Layer 3 (e.g., IP) VPN service. It makes use of 
   the terminology and common components for Layer 3 VPNs defined in 
   [L3VPN-FR] and of the generic VPN terminology defined in [PPVPN-
   TERM].   
    
   The specification of technical means to provide L3VPN services is 
   outside the scope of this document. Other documents, such as the L3 
   VPN framework document [L3VPN-FR] and several sets of documents, one 
   set per each individual technical approach for providing L3VPN 
   services, are intended to cover this aspect. 
    
   Technical approaches targeted by this document include the network-
   based (PE-based) L3 VPN category (aggregated routing VPNs 
   [RFC2547bis] and virtual routers [PPVPN-VR]) and the CE-based L3 
   VPNs category [CE-PPVPN][IPsec-PPVPN]. The document distinguishes 
   L3VPN categories as to where the endpoints of tunnels exist as 
   detailed in the L3VPN framework document [L3VPN-FR]. Terminology 
   regarding whether equipment faces a customer or the service provider 
   network is used to define the various types of L3 VPN solutions.>  
    
   This document is intended as a "checklist" of requirements providing  
   a consistent way to evaluate and document how well each individual 
   approach satisfies specific requirements. The applicability 
   statement documents for each individual approach should present the 
   results of this evaluation. It is not the intent of this document to 
   state a comparison of one approach versus another. 
    
   This document provides requirements from several points of view. It 
   begins with some considerations from a common customer and service 
   provider point of view not covered in the generic provider 
   provisioned VPN requirement document [PPVPN-GR], followed by a 
   customer perspective, and concludes with specific needs of a Service 
   Provider (SP).  
    
   The following L3VPN deployment scenarios are considered within this 
   document: 
    
       1. Internet-wide: VPN sites attached to arbitrary points in 
         the Internet 
    
       2. Single SP/single AS: VPN sites attached to the network of a 
         single provider within the scope of a single AS 
    
   Carugi, McDysan et al Informational - Expires January 2005       5 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
    
       3.Single SP/multiple ASs: VPN sites attached to the network 
         of a single provider consisting of multiple ASs 
    
       4.Cooperating SPs: VPN sites attached to networks of different 
         providers that cooperate with each other to provide the VPN  
         service 
    
   The above deployment scenarios have many requirements in  common. 
   These common requirements include SP requirements for security, 
   privacy, manageability, interoperability and scalability, including 
   service provider projections for number, complexity, and rate of 
   change of customer VPNs over the next several years. When 
   requirements apply to a specific deployment scenario, the above 
   terminology is used to state the context of those particular 
   requirements. 
    
   1.2 Outline 
   The outline of the rest of the document is as follows. Section 2 
   mentions the contributing authors. Section 3 provides definitions of 
   terms and concepts. Section 4 provides requirements that are common 
   to both customers and service providers and are not covered in the 
   generic provider provisioned VPN requirement document [PPVPN-GR]. 
   Section 5 states requirements from a customer perspective. Section 6 
   states network requirements from a service provider perspective. 
   Section 7 states service provider management requirements. Section 8 
   describes security considerations. Section 9 lists acknowledgements. 
   Section 10 provides a list of references cited herein. Section 11 
   lists the authors' addresses. 
    
   2 Contributing Authors 
   This document is the combined effort of the two co-editors and the 
   following contributing authors: 
     Luyuan Fang 
     Ananth Nagarajan 
     Junichi Sumimoto 
     Rick Wilder 
    
   3 Definitions 
   This section provides the definition of terms and concepts used 
   throughout the document. Terminology used herein is taken from 
   [PPVPN-TERM] and [L3VPN-FR]. 
    
   3.1 Virtual Private Network  
    
   "L3 Virtual Private Network" (L3 VPN) refers to the L3 communication 
   between a set of sites, making use of a shared network 
   infrastructure.  
    
   "Provider Provisioned VPN" (PPVPN) refers to VPNs for which the 
   service provider participates in management and provisioning of the 
   VPN. 
    
   Carugi, McDysan et al Informational - Expires January 2005       6 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
    
   3.2 Users, Sites, Customers and Agents 
   User: A user is an entity (e.g., a human being using a host, a 
   server, or a system) that has been authorized to use a VPN service. 
    
   Site: A site is a set of users that have mutual L3 (i.e., IP) 
   reachability without use of a specific service provider network. A 
   site may consist of a set of users that are in geographic proximity.  
   Note that a topological definition of a site (e.g., all users at a 
   specific geographic location) may not always conform to this 
   definition. For example, two geographic locations connected via 
   another provider's network would also constitute a single site since 
   communication between the two locations does not involve the use of 
   the service provider offering the L3 VPN service.  
    
   Customer: A single organization, corporation, or enterprise that 
   administratively controls a set of sites. 
    
   Agent: A set of users designated by a customer who has the 
   authorization to manage a customer's VPN service offering. 
    
   3.3 Intranets, Extranets, and VPNs 
    
   Intranet: An intranet restricts communication to a set of sites that 
   belong to one customer. An example is branch offices at different 
   sites that require communication to a headquarters site.  
    
   Extranet: An extranet allows the specification of communication 
   between a set of sites that belong to different customers. In other 
   words, two or more organizations have access to a specified set of 
   each other's sites.  Examples of an extranet scenario include 
   multiple companies cooperating in joint software development, a 
   service provider having access to information from the vendors' 
   corporate sites, different companies, or universities participating 
   in a consortium.  An extranet often has further restrictions on 
   reachability, for example, at a host and individual transport level. 
    
   Note that an intranet or extranet can exist across a single service 
   provider network with one or more ASs, or across multiple service 
   provider networks.  
    
   L3 Virtual Private Network (L3 VPN): An alternative definition of 
   VPN refers to a specific set of sites as either an intranet or an 
   extranet that have been configured to allow communication. Note that 
   a site is a member of at least one VPN, and may be a member of many 
   VPNs.  
    
   3.4 Networks of Customer and Provider Devices 
   L3VPNs are composed of the following types of devices. 
    
   Customer Edge (CE) device: A CE device faces the users at a customer 
   site. The CE has an access connection to a PE device. It may be a 
    
   Carugi, McDysan et al Informational - Expires January 2005       7 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   router or a switch that allows users at a customer site to 
   communicate over the access network with other sites in the VPN. In 
   a CE-based L3VPN, as intended in this document (provider provisioned 
   CE-based VPN), the service provider manages (at least partially) the 
   CE device. 
    
   Provider Edge (PE) device: A PE device faces the provider network on 
   one side and attaches via an access connection over one or more 
   access networks to one or more CE devices. It participates in the 
   Packet Switched Network (PSN) in performing routing and forwarding 
   functions.  
    
   Note that the definitions of Customer Edge and Provider Edge do not 
   necessarily map to the physical deployment of equipment on customer 
   premises or a provider point of presence.  
    
   Provider (P) device: A device within a provider network that 
   interconnects PE (or other P) devices, but does not have any direct 
   attachment to CE devices. The P router does not keep VPN state and 
   is VPN un-aware [PPVPN-TERM]. 
    
   Packet Switched Network (PSN): A (IP or MPLS) network through which 
   the tunnels supporting the VPN services are set up [PPVPN-TERM]. 
    
   Service Provider (SP) network: An SP network is a set of 
   interconnected PE and P devices administered by a single service 
   provider in one or more ASs.  
    
   3.5 Access Networks, Tunnels, and Hierarchical Tunnels  
   VPNs are built between CEs using access networks, tunnels, and 
   hierarchical tunnels across a PSN.  
    
   Access connection: An access connection provides connectivity 
   between a CE and a PE. This includes dedicated physical circuits, 
   virtual circuits, such as Frame Relay, ATM, Ethernet (V)LAN, or IP 
   tunnels (e.g., IPsec, L2TP).  
    
   Access network: An access network provides access connections 
   between CE and PE devices.  It may be a TDM network, L2 network 
   (e.g. FR, ATM, and Ethernet), or an IP network over which access is 
   tunneled (e.g., using L2TP]).  
    
   Tunnel: A tunnel between two entities is formed by encapsulating 
   packets within another encapsulating header for purpose of 
   transmission between those two entities in support of a VPN 
   application. Examples of protocols commonly used for tunneling are: 
   GRE, IPsec, IP-in-IP tunnels, and MPLS.  
    
   Hierarchical Tunnel: Encapsulating one tunnel within another forms a 
   hierarchical tunnel. The innermost tunnel protocol header defines a 
   logical association between two entities (e.g., between CEs or PEs) 


    
   Carugi, McDysan et al Informational - Expires January 2005       8 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   [VPN TUNNEL]. Note that the tunneling protocols need not be the same 
   at different levels in a hierarchical tunnel.  
 
   3.6 Use of Tunnels and roles of CE and PE in L3 VPNs 
   This section summarizes the point where tunnels terminate and the 
   functions implemented in the CE and PE devices that differentiate 
   the two major categories of L3 VPNs for which requirements are 
   stated, namely PE-based and CE-based L3 VPNs. See the L3VPN 
   framework document for more detail [L3VPN-FR]. 
    
   3.6.1 PE-Based Layer 3 VPNs and Virtual Forwarding Instances 
   In a PE-based layer 3 VPN service, a customer site receives IP layer 
   (i.e., layer 3) service from the SP. The PE is attached via an 
   access connection to one or more CEs. The PE performs forwarding of 
   user data packets based on information in the IP layer header, such 
   as an IPv4 or IPv6 destination address. The CE sees the PE as a 
   layer 3 device such as an IPv4 or IPv6 router. 
    
   Virtual Forwarding Instance (VFI): In a PE-based layer 3 VPN 
   service, the PE contains a VFI for each L3 VPN that it serves. The 
   VFI terminates tunnels for interconnection with other VFIs and also 
   terminates access connections for accommodating CEs. VFI contains 
   information regarding how to forward data received over the CE-PE 
   access connection to VFIs in other PEs supporting the same L3 VPN. 
   The VFI includes the router information base and the forwarding 
   information base for a L3 VPN [L3VPN-FR]. A VFI enables router 
   functions dedicated to serving a particular VPN, such as separation 
   of forwarding and routing and support for overlapping address 
   spaces.  Routing protocols in the PEs and the CEs interact to 
   populate the VFI.  
    
   The following narrative and figures provide further explanation of 
   the way PE devices use tunnels and hierarchical tunnels. Figure 3.1 
   illustrates the case where a PE uses a separate tunnel for each VPN. 
   As shown in the figure, the tunnels provide communication between 
   the VFIs in each of the PE devices.  
    
                  +----------+              +----------+ 
   +-----+        |PE device |              |PE device |        +-----+ 
   | CE  |        |          |              |          |        | CE  | 
   | dev | Access | +------+ |              | +------+ | Access | dev | 
   | of  |  conn. | |VFI of| |    Tunnel    | |VFI of| |  conn. | of  | 
   |VPN A|----------|VPN A |==================|VPN A |----------|VPN A| 
   +-----+        | +------+ |              | +------+ |        +-----+ 
                  |          |              |          | 
   +-----+ Access | +------+ |              | +------+ | Access +-----+ 
   |CE   |  conn. | |VFI of| |    Tunnel    | |VFI of| |  conn. | CE  | 
   | dev |----------|VPN B |==================|VPN B |----------| dev | 
   | of  |        | +------+ |              | +------+ |        | of  | 
   |VPN B|        |          |              |          |        |VPN B| 
   +-----+        +----------+              +----------+        +-----+ 
        Figure 3.1 PE Usage of Separate Tunnels to Support VPNs 
    
   Carugi, McDysan et al Informational - Expires January 2005       9 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
                                     
   Figure 3.2 illustrates the case where a single hierarchical tunnel 
   is used between PE devices to support communication for VPNs. The 
   innermost encapsulating protocol header provides the means for the 
   PE to determine the VPN for which the packet is directed.  
                  +----------+              +----------+ 
   +-----+        |PE device |              |PE device |        +-----+ 
   | CE  |        |          |              |          |        | CE  | 
   | dev | Access | +------+ |              | +------+ | Access | dev | 
   | of  |  conn. | |VFI of| |              | |VFI of| |  conn. | of  | 
   |VPN A|----------|VPN A | | Hierarchical | |VPN A |----------|VPN A| 
   +-----+        | +------+\|   Tunnel     |/+------+ |        +-----+ 
                  |          >==============<          | 
   +-----+ Access | +------+/|              |\+------+ | Access +-----+ 
   | CE  |  conn. | |VFI of| |              | |VFI of| |  conn. | CE  | 
   | dev |----------|VPN B | |              | |VPN B |----------| dev | 
   | of  |        | +------+ |              | +------+ |        | of  | 
   |VPN B|        |          |              |          |        |VPN B| 
   +-----+        +----------+              +----------+        +-----+ 
   Figure 3.2 PE Usage of Shared Hierarchical Tunnels to Support VPNs 
 
   3.6.2 CE-Based L3VPN Tunnel Endpoints and Functions 
    
   Figure 3.3 illustrates the CE-based L3 VPN reference model. In this 
   configuration, typically a single level of tunnel (e.g., IPsec) 
   terminates at pairs of CEs. Usually, a CE serves a single customer 
   site and therefore the forwarding and routing is physically separate 
   from all other customers. Furthermore, the PE is not aware of the 
   membership of specific CE devices to a particular VPN. Hence, the 
   VPN functions are implemented using provisioned configurations on 
   the CE devices and the shared PE and P network is used to only 
   provide the routing and forwarding that supports the tunnel 
   endpoints on between CE devices. The tunnel topology connecting the 
   CE devices may be a full or partial mesh, depending upon VPN 
   customer requirements and traffic patterns. 


















    
   Carugi, McDysan et al Informational - Expires January 2005      10 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
       +---------+  +--------------------------------+  +---------+ 
       |         |  |                                |  |         | 
       |         |  |                 +------+     +------+  : +------+ 
   +------+ :    |  |                 |      |     |      |  : |  CE  | 
   |  CE  | :    |  |                 |  P   |     |  PE  |  : |device| 
   |device| :  +------+    Tunnel     |router|     |device|  : |  of  | 
   |  of  |=:================================================:=|VPN  A| 
   |VPN  A| :  |      |               +------+     +------+  : +------+ 
   +------+ :  |  PE  |                              |  |    :    | 
   +------+ :  |device|                              |  |    :    | 
   |  CE  | :  |      |           Tunnel           +------+  : +------+ 
   |device|=:================================================:=|  CE  | 
   |  of  | :  +------+                            |  PE  |  : |device| 
   |VPN  B| :    |  |                              |device|  : |  of  | 
   +------+ :    |  |  +----------+   +----------+ |      |  : |VPN  B| 
       |    :    |  |  | Customer |   | Network  | +------+  : +------+ 
       |Customer |  |  |management|   |management|   |  |    :    | 
       |interface|  |  | function |   | function |   |  |Customer | 
       |         |  |  +----------+   +----------+   |  |interface| 
       |         |  |                                |  |         | 
       +---------+  +--------------------------------+  +---------+ 
       | Access  |  |<-------- SP network(s) ------->|  | Access  | 
       | network |  |                                |  | network | 
    
                       Figure 3.3 CE-based L3 VPN 
    
   3.7 Customer and Provider Network Management 
   Customer Network Management Function: A customer network management 
   function provides the means for a customer agent 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 use a combination of proprietary 
   network management system, SNMP manager, or directory service (e.g., 
   LDAP [RFC3377] [RFC2251]). 
    
   Provider Network Management Function: A provider network management 
   function provides many of the same capabilities as a customer 
   network management system across all customers. This would not 
   include customer confidential information, such as keying material. 
   The intent of giving the provider a view comparable to that of the 
   customer is to aid in troubleshooting and problem resolution. Such a 
   system also provides the means to query, configure, or receive 
   alarms regarding any infrastructure supporting the L3VPN service. It 
   may use a combination of proprietary network management system, SNMP 
   manager, or directory service (e.g., LDAP [RFC3377] [RFC2251]).  
    






    
   Carugi, McDysan et al Informational - Expires January 2005      11 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
 
   4 Service Requirements Common to Customers and Service Providers 
    
   Many of the requirements that apply to both the customer and the 
   provider and are of an otherwise general nature, or apply to both L2 
   and L3 VPNs, are described in [PPVPN-GR]. This section contains 
   requirements specific to L3 VPNs which are not covered in [PPVPN-
   GR]. 
    
   4.1 Isolated Exchange of Data and Routing Information 
   A mechanism for isolating the distribution of reachability 
   information to only those sites associated with a VPN must be 
   provided.  
    
   L3VPN solutions shall define means that prevent routers in a VPN 
   from interaction with unauthorized entities and avoid introducing 
   undesired routing information that could corrupt the VPN 
   routing information base [VPN-CRIT]. 
    
   A means to constrain, or isolate, the distribution of addressed data 
   to only those VPN sites determined either by routing data and/or 
   configuration must be provided.  
    
   A single site shall be capable of being in multiple VPNs. The VPN 
   solution must ensure that traffic is exchanged only with those sites 
   that are in the same VPN. 
    
   The internal structure of a VPN should not be advertised nor 
   discoverable from outside that VPN. 
    
   Note that isolation of forwarded data and/or exchange of 
   reachability information to only those sites that are part of a VPN 
   may be viewed as a form of security, for example, [Y.1311.1],[MPLS 
   SEC]. 
    
   4.2 Addressing 
    
   IP addresses must be unique within the set of sites reachable from 
   the VPNs of which a particular site is a member. 
    
   A VPN solution must support IPv4 and IPv6 as both the encapsulating 
   and encapsulated protocol. 
    
   If a customer has private or non-unique IP addresses, then a VPN 
   service SHOULD be capable of translating such customer private or 
   non-unique IP addresses for communicating with IP systems having 
   public addresses. 
    
    
   4.3 Quality of Service 
   To the extent possible, L3 VPN QoS should be independent of the 
   access network technology.  
    
   Carugi, McDysan et al Informational - Expires January 2005      12 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
    
   4.3.1 QoS Standards 
   A non-goal of the L3 VPN WG effort (as chartered) is the development 
   of new protocols or extension of existing ones. With regards to QoS 
   support, a L3 VPN shall be able to support QoS in one or more of the 
   following already defined modes: 
     - Best Effort  (mandatory support for all L3VPN types) 
     - Aggregate CE Interface Level QoS ("hose" level QoS) 
     - Site-to-site ("pipe" level QoS) 
     - Intserv (i.e., RSVP) signaled  
     - Diffserv marked 
     - Across packet-switched access networks 
      
   Note that all cases involving QoS may require that the CE and/or PE 
   perform shaping and/or policing.  
    
   L3VPN CEs should be capable of supporting integrated services 
   (Intserv) for certain customers in support of session applications, 
   such as switched voice or video. Intserv-capable CE devices shall 
   support the following Internet standards: 
     - Resource reSerVation Protocol (RSVP) [RFC 2205] 
     - Guaranteed Quality of Service providing a strict delay bound 
       [RFC 2212] 
     - Controlled Load Service providing performance equivalent to that 
   of an unloaded network [RFC 2211] 
      
   L3VPN CE and PE should be capable of supporting differentiated 
   service (Diffserv). .  Diffserv-capable L3VPN CE and PE shall 
   support the following per hop behavior (PHB) [RFC 2475] types: 
     - Expedited Forwarding (EF) - the departure rate of an aggregate 
   class of traffic from a device that must equal or exceed a 
   configured rate [RFC 3246]. 
     - Assured Forwarding (AF) - a means for a provider Diffserv (DS) 
   domain to offer different levels of forwarding assurances for IP 
   packets received from a customer DS domain.  Four AF classes are 
   defined, where each AF class implies allocation in each DS node of a 
   certain amount of forwarding resources (e.g., buffer space and 
   bandwidth) [RFC 2597]. 
    
   A CE or PE device supporting a L3 VPN service may classify a packet 
   for a particular Intserv or Diffserv service based on upon one or 
   more of the following IP header fields: protocol ID, source port 
   number, destination port number, destination address, or source 
   address.   
    
   For a specifiable set of Internet traffic, L3 VPN devices should 
   support Random Early Detection (RED) to provide graceful degradation 
   in the event of network congestion. 
      
    



    
   Carugi, McDysan et al Informational - Expires January 2005      13 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   4.3.2 Service Models 
   A service provider must be able to offer QoS service to a customer 
   for at least the following generic service types: managed access VPN 
   service or edge-to-edge QoS VPN service [PPVPN-GR]. More detail 
   specific to L3 VPNs is provided below. 
    
   A managed access L3 VPN service provides QoS on the access 
   connection between the CE and the PE. For example, diffserv would be 
   enabled only on the CE router and the customer-facing ports of the 
   PE router. Note that this service would not require Diffserv 
   implementation in the SP backbone. The SP may use policing for 
   inbound traffic at the PE. The CE may perform shaping for outbound 
   traffic. Another example of a managed access L3 VPN service is where 
   the SP performs the packet classification and diffserv marking. An 
   SP may provide several packet classification profiles that customers 
   may select, or may offer custom profiles based upon customer 
   specific requirements. In general, more complex QoS policies should 
   be left to the customer for implementation. 
    
   An edge-to-edge QoS VPN service provides QoS from edge device to 
   edge device. The edge device may be either PE or CE depending upon 
   the service demarcation point between the provider and the customer. 
   Such a service may be provided across one or more provider 
   backbones. The CE requirements for this service model are the same 
   as the managed access VPN service. However, in this service QoS is 
   provided from one edge of the SP network(s) to the other edge. 
    
   4.4 Service Level Specification and Agreements 
    
   A generic discussion of SLAs is provided in [PPVPN-GR]. 
   Additionally, SLS measurements for quality based on the DiffServ 
   scheme SHOULD be based upon the following classification: 
    
       . A Point-to-Point SLS [Y.1311.1], sometimes also referred to as 
          the "Pipe" model, defines traffic parameters in conjunction 
          with the QoS objectives for traffic exchanged between a pair 
          of VPN sites (i.e., points). A Point-to-Point SLS is analogous 
          to the SLS typically supported over point-to-point Frame Relay 
          or ATM PVCs or an edge-to-edge MPLS tunnel. The set of SLS 
          specifications to all other reachable VPN sites would define 
          the overall Point-to-Point SLS for a specific site. 
    
       . A Point-to-Cloud SLS [Y.1311.1], sometimes also referred as 
          the "Hose" model, defines traffic parameters in conjunction 
          with the QoS objectives for traffic exchanged between a CE and 
          a PE for traffic destined to a set (either all or a subset) of 
          other sites in the VPN (i.e., the cloud), as applicable. In 
          other words, a point-to-cloud SLS defines compliance in terms 
          of all packets transmitted from a given VPN site toward the SP 
          network on an aggregate basis (i.e., regardless of the 
          destination VPN site of each packet).  
    
    
   Carugi, McDysan et al Informational - Expires January 2005      14 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
       . A Cloud-to-Point SLS (a case not covered by this SLS is where 
          flows originating from multiple sources may congest the 
          interface from the network toward a specific site). 
    
   Traffic parameters and actions SHOULD be defined for packets to and 
   from the demarcation between the service provider and the site. For 
   example, policing may be defined on ingress and shaping on egress. 
    
   4.5 Management 
   An SP and its customers MUST be able to manage the capabilities and 
   characteristics of their VPN services. To the extent possible, 
   automated operations and interoperability with standard management 
   platforms SHOULD be supported.   
    
   The ITU-T Telecommunications Management Network (TMN) model has the 
   following generic requirements structure: 
     O Engineer, deploy and manage the switching, routing and 
     transmission resources supporting the service, from a network 
     perspective (network element management); 
     O Manage the VPN networks deployed over these resources (network 
     management); 
     o Manage the VPN service (service management);  
     o Manage the VPN business, mainly provisioning administrative and 
     accounting information related to the VPN service customers 
     (business management). 
    
   Service management should include the TMN 'FCAPS' functionalities, 
   as follows: Fault, Configuration, Accounting, Provisioning, and 
   Security, as detailed in section 7.  
    
    
   4.6 Interworking 
   Interworking scenarios among different solutions providing L3VPN 
   services is highly desirable. See the L3VPN framework document for 
   more details on interworking scenarios [L3VPN-FR]. Interworking 
   SHOULD be supported in a scalable manner.  
    
   Interworking scenarios MUST consider at least traffic and routing 
   isolation, security, QoS, access, and management aspects. This 
   requirement is essential in the case of network migration, to ensure 
   service continuity among sites belonging to different portions of 
   the network.  
    
   5 Customer Requirements 
   This section captures additional requirements from a customer 
   perspective. 
    
   5.1 VPN Membership (Intranet/Extranet) 
   When an extranet is formed, a customer agent from each of the 
   organizations first approves addition of a site to an extranet VPN 
   as a business decision between the parties involved. The solution 
   SHOULD provide a means such that these organizations can control 
    
   Carugi, McDysan et al Informational - Expires January 2005      15 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   extranet communication involving the L3VPN exchange of traffic and 
   routing information. 
    
   5.2 Service Provider Independence 
   Customers MAY require VPN service that spans multiple administrative 
   domains or service provider networks. Therefore, a VPN service MUST 
   be able to span multiple AS and SP networks, but still act and 
   appear as a single, homogenous VPN from a customer point of view.  
    
   A customer might also start with a VPN provided in a single AS with 
   a certain SLA but then ask for an expansion of the service spanning 
   multiple ASs/SPs. In this case, as well as for all kinds of multi-
   AS/SP VPNs, VPN service SHOULD be able to deliver the same SLA to 
   all sites in a VPN regardless of the AS/SP to which it homes.  
    
   5.3 Addressing 
   A customer requires support from a L3 VPN for the following 
   addressing IP assignment schemes:  
     o customer assigned, non-unique, or RFC 1918 private addresses 
     o globally unique addresses obtained by the customer 
     o globally unique addresses statically assigned by the L3VPN 
     service provider 
     o on-demand, dynamically assigned IP addresses (e.g., DHCP), 
     irrespective of whether the access is temporary (e.g., remote) or 
     permanent (i.e., dedicated) 
    
   In the case of combined L3 VPN service with non-unique or private 
   addresses and Internet access, mechanisms that permit the exchange 
   of traffic between the customer's address space and the global 
   unique Internet address space MAY be supported. For example, NAT is 
   employed by many customers and some service providers today to meet 
   this need. A preferred solution would be to assign unique addresses, 
   either IPv4 or IPv6; however, some customers do not want to renumber 
   their networks. 
     
   5.4 Routing Protocol Support 
   There SHOULD be no restriction on the routing protocols used between 
   CE and PE routers, or between CE routers. At least the following 
   protocols MUST be supported: static routing, IGP protocols, such as 
   RIP, OSPF, IS-IS, and BGP [L3VPN-FR]. 
    
   5.5 Quality of Service and Traffic Parameters 
   QoS is expected to be an important aspect of a L3VPN service for 
   some customers. QoS requirements cover scenarios involving an 
   intranet, an extranet, as well as shared access between a VPN site 
   and the Internet. 
    
   5.5.1 Application Level QoS Objectives 
   A customer is concerned primarily that the L3VPN service provide his 
   or her applications with the QoS and level of traffic such that the 
   applications perform acceptably. Voice and interactive video, and 
   multimedia applications are expected to require the most stringent 
    
   Carugi, McDysan et al Informational - Expires January 2005      16 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   QoS. These real-time applications are sensitive to delay, delay 
   variation, loss, availability and/or reliability. Another set of 
   applications, including some multimedia and interactive video 
   applications, high-performance web browsing and file transfer 
   intensive applications, requires near real time performance. 
   Finally, best effort applications are not sensitive to degradation, 
   that is are elastic and can adapt to conditions of degraded 
   performance. 
    
   The selection of appropriate QoS and service type to meet specific 
   application requirements is particularly important to deal with 
   periods of congestion in a SP network. Sensitive applications will 
   likely select per-flow Integrated service (Intserv) with precise SLA 
   guarantees measured on a per flow basis. On the other hand, non-
   sensitive applications will likely rely on a Diffserv class-based 
   QoS. 
    
   The fundamental customer application requirement is that a L3VPN 
   solution MUST support both the Intserv QoS model for selected 
   individual flows, and Diffserv for aggregated flows.     
    
   A customer application SHOULD experience consistent QoS independent 
   of the access network technology used at different sites connected 
   to the same VPN. 
    
   5.5.2 DSCP Transparency 
   The Diffserv Code Point (DSCP) set by a user as received by the 
   ingress CE SHOULD be capable of being relayed transparently to the 
   egress CE [see section 2.6.2 of RFC 3270 and Y.1311.1]. Although RFC 
   2475 states that interior or boundary nodes within a DS domain can 
   change the DSCP, customer VPNs MAY have other requirements, such as: 
     o Applications that use the DSCP in a manner differently than the 
     DSCP solution supported by the SP network(s); 
     o Customers using more DSCPs within their sites than the SP 
     network(s) supports; 
     o Support for a carrier's carrier service where one SP is the 
     customer of another L3VPN SP. Such an SP should be able to resell 
     VPN service to his or her  VPN customers independently of the DSCP 
     mapping solution supported by the carrier's carrier SP. 
      
   Note that support for DSCP transparency has no implication on the 
   QoS or SLA requirements. If an SP supports DSCP transparency, then 
   that SP needs to only carry the DSCP values across its domain, but 
   MAY map the received DSCP to some other value for QoS support across 
   its domain. 
    
   5.6 Service Level Specification/Agreement 
   Most customers simply want their applications to perform well. An 
   SLA is a vehicle for customer recourse in the event that SP(s) do 
   not perform or manage a VPN service well in a measurable sense. 
   Therefore, when purchasing service under an SLA, a customer agent 


    
   Carugi, McDysan et al Informational - Expires January 2005      17 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   MUST have access to the measures from the SP(s) that support the 
   SLA.    
    
   5.7 Customer Management of a VPN 
   A customer MUST have a means to view the topology, operational 
   state, order status, and other parameters associated with his or her 
   VPN.  
    
   Most aspects of management information about CE devices and customer 
   attributes of a L3VPN manageable by an SP SHOULD be capable of being 
   configured and maintained by an authenticated, authorized customer 
   agent. However, some aspects, such as encryption keys, SHALL NOT be 
   readable nor writable by management systems. 
    
   A customer agent SHOULD be able to make dynamic requests for changes 
   to traffic parameters. A customer SHOULD be able to receive real-
   time response from the SP network in response to these requests.  
   One example of such service is a "Dynamic Bandwidth management" 
   capability, that enables real-time response to customer requests for 
   changes of allocated bandwidth allocated to his or her VPN 
   [Y.1311.1].  
    
   A customer who may not be able to afford the resources to manage his 
   own sites SHOULD be able to outsource the management of the entire 
   VPN to the SP(s) supporting the VPN network.   
    
   5.8 Isolation 
   These features include traffic and routing information exchange 
   isolation, similar to that obtained in VPNs based on Layer 1 and 
   Layer 2 (e.g., private lines, FR, or ATM) [MPLS SEC]. 
    
   5.9 Security 
   The suite of L3VPN solutions SHOULD support a range of security 
   related features.  Higher levels of security services, like edge-to-
   edge encryption, authentication, or replay attack should be 
   supported. More details on customer requirements for security are 
   described in [VPNSEC]. 
    
   Security in a L3VPN service SHOULD be as transparent as possible to 
   the customer, with the obvious exception of support for remote or 
   temporary user access, as detailed in section 5.11.2.  
    
   L3VPN customers MUST be able to deploy their own internal security 
   mechanisms in addition to those deployed by the SP, in order to 
   secure specific applications or traffic at a granularity finer than 
   a site-to-site basis.  
     
   If a customer requires QoS support in a L3 VPN, then this request 
   MUST be communicated to the SP either using unencrypted fields or 
   else via an agreed security association. For example, applications 
   could send RSVP messages in support of Intserv either in the clear 
   or encrypted using a key negotiated with the SP. Another case is 
    
   Carugi, McDysan et al Informational - Expires January 2005      18 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   where applications using an IPsec tunnel could copy the DSCP from 
   the encrypted IP header to the header of the tunnel's IP header.  
    
    
   5.10  Migration Impact 
   Often, customers are migrating from an already deployed private 
   network toward one or more L3 VPN solutions. A typical private 
   network scenario is CE routers connected via real or virtual 
   circuits. Ideally, minimal incremental cost SHOULD result during the 
   migration period. Furthermore, if necessary, any disruption of 
   service SHOULD also be minimized. 
    
   A range of scenarios of customer migration MUST be supported. Full  
   migration of all sites MUST be supported. Support for cases of 
   partial migration is highly desirable [Y.1311.1], that is, legacy 
   private network sites that belong to the L3VPN service SHOULD still 
   have L3 reachability to the sites that migrate to the L3VPN service. 
    
   5.11  Network Access 
   Every L3 packet exchanged between the customer and the SP over the 
   access connection MUST appear as it would on a private network 
   providing an equivalent service to that offered by the L3VPN. 
    
   5.11.1 Physical/Link Layer Technology  
   L3VPNs SHOULD support a broad range of physical and link layer 
   access technologies, such as PSTN, ISDN, xDSL, cable modem, leased 
   line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local 
   loop, mobile radio access, etc. The capacity and QoS achievable may 
   be dependent on the specific access technology in use. 
    
   5.11.2 Temporary Access 
   The VPN service offering SHOULD allow both permanent and temporary 
   access to one or more L3VPNs for authenticated users across a broad 
   range of access technologies. Support for remote or temporary VPN 
   access SHOULD include ISDN, PSTN dial-in, xDSL or access via another 
   SP network. The customer SHOULD be able to choose from alternatives 
   for authentication of temporary access users. Choices for access 
   authentication are: SP-provided, third-party, or customer-provided 
   authentication.   
    
   A significant number of VPN users may not be permanently attached to 
   one VPN site : in order to limit access to a VPN to only authorized 
   users, it is first necessary to authenticate them. Authentication 
   SHALL apply as configured by the customer agent and/or SP where a 
   specific user may be part of one or more VPNs. The authentication 
   function SHOULD be used to automatically invoke all actions 
   necessary to join a user to the VPN.  
    
   A user SHOULD be able to access a L3VPN via a network having generic 
   Internet access. 
    


    
   Carugi, McDysan et al Informational - Expires January 2005      19 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   Mobile users may move within a L3VPN site. Mobile users may also 
   have temporary connections to different L3VPN site within the same 
   VPN. Authentication SHOULD be provided for both of these cases.  
    
   5.11.3 Sharing of the Access Network 
   In a PE-based L3VPN, if the site shares the access network with 
   other traffic (e.g., access to the Internet), then data security in 
   the access network is the responsibility of the L3VPN customer. 
 
   5.11.4 Access Connectivity 
   Various types of physical connectivity scenarios MUST be supported, 
   such as multi-homed sites, backdoor links between customer sites, 
   devices homed to two or more SP networks. L3VPN solutions SHOULD 
   support at least the types of physical or link-layer connectivity 
   arrangements shown in Figure 5.1. Support for other physical 
   connectivity scenarios with arbitrary topology is desirable.  
    
   Access arrangements with multiple physical or logical paths from a 
   CE to other CEs and PEs MUST support redundancy, and SHOULD support 
   load balancing. Resiliency uses redundancy to provide connectivity 
   between a CE site and other CE sites, and optionally, other 
   services. Load balancing provides a means to perform traffic 
   engineering such that capacity on redundant links is used to achieve 
   improved performance during periods when the redundant component(s) 
   are available. 
    
   For multi-homing to a single SP, load balancing capability SHOULD be 
   supported by the PE across the CE to PE links. For example, in case 
   (a), load balancing SHOULD be provided by the two PEs over the two 
   links connecting to the single CE. In case (c), load balancing 
   SHOULD be provided by the two PEs over the two links connecting to 
   the two CEs.  
    
   In addition, the load balancing parameters (e.g., the ratio of 
   traffic on the multiple load-balanced links, or the preferred link) 
   SHOULD be provisionable based on customer's requirements. The load 
   balancing capability may also be used to achieve resiliency in the 
   event of access connectivity failures. For example, in cases (b) a 
   CE may connect to two different SPs via diverse access networks. 
   Resiliency MAY be further enhanced as shown in case (d), where CEs 
   connected via a "back door" connection connect to different SPs.   
   Furthermore, arbitrary combinations of the above methods, with a few 
   examples shown in cases (e) and (f) should be supportable by any 
   L3VPN approach. 
    
   For multi-homing to multiple SPs, load balancing capability MAY also 
   be supported by the PEs in the different SPs (clearly, this is a 
   more complex type of load balancing to realize, and requires policy 
   and service agreements between the SPs to interoperate). 
    
    


    
   Carugi, McDysan et al Informational - Expires January 2005      20 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
                  +----------------                    +--------------- 
                  |                                    | 
               +------+                            +------+ 
     +---------|  PE  |                  +---------|  PE  | 
     |         |router|                  |         |router| SP network 
     |         +------+                  |         +------+ 
  +------+         |                  +------+         | 
  |  CE  |         |                  |  CE  |         +--------------- 
  |device|         |   SP network     |device|         +--------------- 
  +------+         |                  +------+         | 
     |         +------+                  |         +------+ 
     |         |  PE  |                  |         |  PE  | 
     +---------|router|                  +---------|router| SP network 
               +------+                            +------+ 
                   |                                   | 
                   +----------------                   +--------------- 
                  (a)                                 (b) 
                   +----------------                  +--------------- 
                   |                                  | 
  +------+     +------+               +------+     +------+ 
  |  CE  |-----|  PE  |               |  CE  |-----|  PE  | 
  |device|     |router|               |device|     |router| SP network 
  +------+     +------+               +------+     +------+ 
     |             |                     |             | 
     | Backdoor    |                     | Backdoor    +--------------- 
     | link        |   SP network        | link        +--------------- 
     |             |                     |             | 
  +------+     +------+               +------+     +------+ 
  |  CE  |     |  PE  |               |  CE  |     |  PE  | 
  |device|-----|router|               |device|-----|router| SP network 
  +------+     +------+               +------+     +------+ 
                   |                                   | 
                   +----------------                   +--------------- 
                  (c)                                  (d) 
                   +----------------                   +--------------- 
                   |                                   | 
  +------+     +------+               +------+     +------+ 
  |  CE  |-----|  PE  |               |  CE  |-----|  PE  | 
  |device|     |router|               |device|     |router| SP network 
  +------+\    +------+               +------+\    +------+ 
     |     \       |                     |     \       | 
     |Back  \      |                     |Back  \      +--------------- 
     |door   \     |   SP network        |door   \     +--------------- 
     |link    \    |                     |link    \    | 
  +------+     +------+               +------+     +------+ 
  |  CE  |     |  PE  |               |  CE  |     |  PE  | 
  |device|-----|router|               |device|-----|router| SP network 
  +------+     +------+               +------+     +------+ 
                   |                                   | 
                   +----------------                   +--------------- 
                  (e)                                 (f) 
        Figure 5.1 Representative types of access arrangements. 
    
   Carugi, McDysan et al Informational - Expires January 2005      21 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
    
    
   5.12  Service Access  
   Customers MAY also require access to other services, as described in 
   this section.  
    
   5.12.1 Internet Access 
   Customers SHOULD be able to have L3 VPN and Internet access across 
   the same access network for one or more of the customer's sites.  
    
   Customers SHOULD be able to direct Internet traffic from the set of 
   sites in the L3VPN to one or more customer sites that have 
   firewalls, other security-oriented devices, and/or NAT that process 
   all traffic between the Internet and the customer's VPN.  
    
   L3 VPN Customers SHOULD be able to receive traffic from the Internet 
   addressed to a publicly accessible resource that is not part of the 
   VPN, such as an enterprise's public web server.  
    
   As stated in section 5.3, if a customer L3 VPN employs private or 
   non-unique IP addresses, then network address translation (NAT) or a 
   similar mechanism MUST be provided either by the customer or the SP 
   in order to be able to exchange traffic with devices outside the 
   customer's L3 VPN. 
    
   5.12.2 Hosting, Application Service Provider 
   A customer SHOULD be able to access hosting, other application 
   services, or other Application Service Providers (ASP) over a L3 
   L3VPN service. This MAY require that an ASP participates in one or 
   more VPNs with the customers that use such a service. 
    
   5.12.3 Other Services  
   In conjunction with a VPN service, a customer MAY also wish to have 
   access to other services, such as: DNS, FTP, HTTP, NNTP, SMTP, LDAP, 
   VoIP, NAT, LDAP, Videoconferencing, Application sharing, E-business, 
   Streaming, E-commerce, Directory, Firewall, etc. The resources that 
   implement these services could be physically dedicated to each VPN. 
   If the resources are logically shared, then they MUST have access 
   separated and isolated between VPNs in a manner consistent with the 
   L3VPN solution to meet this requirement.  
    
   5.13  Hybrid VPN Service Scenarios 
   Intranet or extranet customers have a number of reasons for wanting 
   hybrid networks that involve more than one VPN solution type. These 
   include migration, mergers, extranet customers with different VPN 
   types, the need for different capabilities between different sets of 
   sites, temporary access, different availability of VPN solutions as 
   provided by different service providers.  
    
   The framework and solution approaches SHOULD include provisions for 
   interworking, interconnection, and/or reachability between different 


    
   Carugi, McDysan et al Informational - Expires January 2005      22 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   L3VPN solutions in such a way that does not overly complicate 
   provisioning, management, scalability, or performance. 
    
   6 Service Provider Network Requirements 
   This section describes requirements from a service provider 
   perspective. 
    
   6.1 Scalability 
   [PPVPN-GR} lists projections regarding L3VPN sizing  and scalability 
   requirements and metrics related to specific solutions. 
    
   6.2 Addressing  
   As described in section 4.2, SPs MUST have support for public and 
   private IP addresses, IPv4 and IPv6, for both unicast and multicast. 
   In order to support this range of addressing schemes, SPs require 
   the following support from L3VPN solutions. 
    
   A L3VPN solution MUST be able to assign blocks of addresses from its 
   own public IP address space to L3VPN customer sites in such a way 
   that advertisement of routes to other SPs and other sites aggregates 
   efficiently. 
    
   A L3VPN solution MUST be able to use address assignments made by a 
   customer. These customer assigned addresses may be public, or 
   private. 
    
   In the case where private IP addresses are used, a L3VPN solution 
   MUST provide a means for an SP to translate such addresses to public 
   IP addresses for communication with other VPNs using overlapping 
   addresses, or the Internet. 
    
   6.3 Identifiers 
   A number of identifiers MAY be necessary for SP use in management, 
   control, and routing protocols. Requirements for at least the 
   following identifiers are known. 
    
   An SP domain MUST be uniquely identified at least within the set of 
   all interconnected SP networks when supporting a VPN that spans 
   multiple SPs. Ideally, this identifier should be globally unique 
   (e.g., an AS number).   
    
   An identifier for each VPN SHOULD be unique, at least within each 
   SP's network. Ideally, the VPN identifier SHOULD be globally unique 
   to support the case where a VPN spans multiple SPs (e.g., [RFC 
   2685]). 
    
   A CE device SHOULD have a unique identifier, at least within each 
   SP's network. 
    
   A PE device SHOULD have a unique identifier, at least within each 
   SP's network. 
    
    
   Carugi, McDysan et al Informational - Expires January 2005      23 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   The identifier of a device interconnecting SP networks MUST be 
   unique within the set of aforementioned networks. 
    
   Each site interface SHOULD have a unique identifier, at least within 
   each PE router supporting such an interface. 
    
   Each tunnel SHOULD have a unique identifier, at least within each 
   router supporting the tunnel. 
    
   6.4 Discovering VPN Related Information 
   Configuration of CE and PE devices is a significant task for a 
   service provider. Solutions SHOULD strive to contain methods that 
   dynamically allow VPN information to be discovered (or learned) by 
   the PE and/or CE to reduce configuration complexity. The following 
   specific requirements apply to intra and inter-provider VPNs [VPN 
   DISC]. 
    
   Every device involved in a VPN SHALL be able to identify and 
   authenticate itself to other devices in the VPN. After learning the 
   VPN membership, the devices SHOULD be able to securely exchange 
   configuration information. The VPN information MUST include at least 
   the IP address of the PE and may be extensible to provide additional 
   information. 
    
   Each device in a VPN SHOULD be able to determine which other devices 
   belong to the same VPN.  Such a membership discovery scheme MUST 
   prevent unauthorized access and allow authentication of the source.    
    
   Distribution of VPN information SHOULD be limited to those devices 
   involved in that VPN. 
    
   In the case of a PE-based VPN, a solution SHOULD support the means 
   for attached CEs to authenticate each other and verify that the SP's 
   VPN network is correctly configured. 
    
   The mechanism SHOULD respond to VPN membership changes in a timely 
   manner. A "timely manner" is no longer than the provisioning 
   timeframe, typically on the order of minutes, and could be as short 
   as the timeframe required for "rerouting," typically on the order of 
   seconds. 
    
   Dynamically creating, changing, and managing multiple VPN 
   assignments to sites and/or customers is another aspect of 
   membership that MUST be addressed in a L3 VPN solution.   
    
   6.5 SLA and SLS Support 
   Typically, a Service Provider offering a L3VPN service commits to 
   specific Service Level Specifications (SLS) as part of a contract 
   with the customer, as described in section 4.4 and [PPVPN-GR]. Such 
   a Service Level Agreement (SLA) implies SP requirements for 
   measuring Specific Service Level Specifications (SLS) for quality, 
   availability, response time, and configuration intervals. 
    
   Carugi, McDysan et al Informational - Expires January 2005      24 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
    
   6.6 Quality of Service (QoS) and Traffic Engineering 
   A significant aspect of a L3VPN is support for QoS. Since an SP has 
   control over the provisioning of resources and configuration of 
   parameters in at least the PE and P devices, and in some cases, the 
   CE device as well, the onus is on the SP to provide either managed 
   QoS access service, or edge-to-edge QoS service, as defined in 
   section 4.3.2.  
    
   Each L3VPN approach MUST describe the traffic engineering techniques 
   available for a SP to meet the QoS objectives. These descriptions of 
   traffic engineering techniques SHOULD quantify scalability and 
   achievable efficiency. Traffic engineering support MAY be on an 
   aggregate or per-VPN basis. 
    
   QoS policies MUST not be impacted by security mechanisms. For 
   example, Diffserv policies MUST not be impacted by the use of IPSec 
   tunnels, using the mechanisms explained in RFC 2983.  
    
   As stated in RFC 2475, a mapping function from customer provided 
   Diffserv marking to marking used in a SP network should be provided 
   for L3 VPN services.  
    
   In the case where a customer requires DSCP transparency, as 
   described in section 5.5.2, a L3 VPN service MUST deliver the same 
   value of DSCP field in the IP header received from the customer to 
   the egress demarcation of the destination.  
    
   6.7 Routing 
   The distribution of reachability and routing policy SHOULD be 
   constrained to the sites that are members of the VPN.  
    
   Optionally, the exchange of such information MAY use some form of 
   authentication (e.g., MD5).  
    
   Functions to isolate the SP network and customer VPNs from anomalous 
   routing behavior from a specific set of customer sites SHOULD be 
   provided. Examples of such functions are: controls for route flap 
   dampening, filters that accept only prefixes configured for a 
   specific CE, a maximum number of routes accepted for each CE, or a 
   maximum rate at which route updates can be received from a CE. 
    
   When VPN customers use overlapping, non-unique IP addresses, the 
   solution MUST define a means to distinguish between such overlapping 
   addresses on a per-VPN basis.   
    
   Furthermore, the solution SHOULD provide an option that either 
   allows, or prevents advertisement of VPN routes to the Internet. 
    
   Ideally, the choice of a SP's IGP SHOULD not depend on the routing 
   protocol(s) used between PE and CE routers in a PE-based VPN. 


    
   Carugi, McDysan et al Informational - Expires January 2005      25 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   Furthermore, it is desirable that an SP SHOULD have a choice with 
   regards to the IGP routing protocol. 
    
   The additional routing burden that an SP must carry should be 
   articulated in each specific L3 VPN solution. 
    
   6.8 Isolation of Traffic and Routing 
   The internal structure of a L3VPN network SHOULD not be visible to 
   outside networks (i.e., the Internet or any connected VPN).  
    
   From a high level SP perspective, a PE-based L3VPN MUST isolate the 
   exchange of traffic and routing information to only those sites that 
   are authenticated and authorized members of a VPN.  
    
   In a CE-based VPN, the tunnels that connect the sites effectively 
   meet this isolation requirement if both traffic and routing 
   information flow over the tunnels. 
    
   A L3VPN solution SHOULD provide a means for meeting L3VPN QoS SLA 
   requirements that isolates VPN traffic from the affects of traffic 
   offered by non-VPN customers. Also, L3VPN solutions SHOULD provide a 
   means to isolate the effects that traffic congestion produced by 
   sites as part of one VPN can have on another VPN. 
    
   6.9 Security 
   This section contains requirements related to securing customer 
   flows, providing authentication services for temporary, remote or 
   mobile users, and the need to protect service provider resources 
   involved in supporting a L3VPN. More detailed security requirements 
   are provided in [VPNSEC]. 
    
   6.9.1 Support for Securing Customer Flows 
   In order to meet the general requirement for providing a range of 
   security options to a customer, each L3VPN solution MUST clearly 
   spell out the configuration options that can work together and how 
   the can do so. 
    
   When a VPN solution operates over a part of the Internet, it should 
   support a configurable option to support one or more of the 
   following standard IPsec methods for securing a flow for a specified 
   subset of a customer's VPN traffic: 
     o confidentiality, so that only authorized devices can decrypt it, 
     o integrity, to ensure that the data has not been altered, 
     o authentication, to ensure that the sender is indeed who he or she 
     claims to be, 
     o replay attack prevention. 
    
   The above functions SHOULD be capable of being applied to "data 
   traffic" of the customer, which includes the traffic exchanged 
   between sites, between temporary users and sites and even between 
   temporary users. It SHOULD also be possible to apply these functions 
   to "control traffic", such as routing protocol exchanges, that are 
    
   Carugi, McDysan et al Informational - Expires January 2005      26 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   not necessarily perceived by the customer but nevertheless essential 
   to maintain his or her VPN.  
    
   Furthermore, such security methods MUST be configurable between 
   different end points, such as CE-CE, PE-PE, and CE-PE. It is also 
   desirable to configure security on a per-route or per-VPN basis [VPN 
   SEC]. 
    
   A VPN solution MAY support one or more encryption schemes, including 
   AES, 3DES. Encryption, decryption, and key management SHOULD be 
   included in profiles as part of the security management system.  
    
   6.9.2 Authentication Services 
   A service provider MUST provide authentication services in support 
   of temporary user access requirements, as described in section 
   5.11.2. 
    
   Furthermore, traffic exchanged within the scope of VPN MAY involve 
   several categories of equipment that must cooperate together to 
   provide the service [Y.1311.1]. These network elements can be CE, 
   PE, firewalls, backbone routers, servers, management stations, etc. 
   These network elements learn about each others identity, either via 
   manual configuration or via discovery protocols, as described in 
   section 6.4. When network elements must cooperate, these network 
   elements SHALL authenticate peers before providing the requested 
   service. This authentication function MAY also be used to control 
   access to network resources. 
    
   The peer identification and authentication function described above 
   applies only to network elements participating in the VPN. Examples 
   include: 
   - traffic between a CE and a PE, 
   - traffic between CEs belonging to the same VPN, 
   - CE or PE routers dealing with route announcements for a VPN, 
   - policy decision point [RFC 3198] and a network element, 
   - management station and an SNMP agent. 
    
   Each L3VPN solution SHOULD describe for a peer authentication 
   function: where it is necessary, how it shall be implemented, how 
   secure it must be, and the way to deploy and maintain identification 
   and authentication information necessary to operate the service.  
    
   6.9.3 Resource Protection 
   Recall from the definitions in section 3.3, that a site can be part 
   of an intranet with sites from the only same organization, part of 
   an extranet involving sites from other organizations, have access to 
   the Internet, or any combination of these scopes of communication. 
   Within these contexts, a site might be subject to various attacks 
   coming from different sources. Potential sources of attack include:  
   - users connected to the supporting public IP backbone,  
   - users from the Internet,  


    
   Carugi, McDysan et al Informational - Expires January 2005      27 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   - users from temporary sites belonging to the intranet and/or 
   extranet VPN that the site is part of. 
    
   Security threats and risks that a site may encounter include the 
   following: 
     - denial of service, for example mail spamming, access connection 
     congestion, TCP SYN attacks, ping attacks, etc. 
     - intrusion attempts, which may eventually lead to denial of 
     service (e.g. a Trojan horse attack). 
    
   Additional threat scenarios are defined in [VPNSEC]. A L3 VPN 
   solution MUST state how it addresses each potential threat scenario.  
 
   The devices in the L3VPN network must provide some means of 
   reporting intrusion attempts to the service provider resources. 
    
   6.10  Inter-AS (SP)VPNs  
   The scenario for VPNs spanning multiple Autonomous Systems (AS) or 
   Service Providers (SP) requires standard solutions.  The scenario 
   where multiple ASs are involved is the most general case, and is 
   therefore the one described here.  The scenarios of concern are the 
   CE-based and PE-based L3 VPNs defined in section 3.  
    
   In each scenario, all applicable SP requirements, such as traffic 
   and routing isolation, SLA's, management, security, provisioning, 
   etc. MUST be preserved across adjacent ASs. The solutions MUST 
   describe the inter-SP network interface, encapsulation method(s), 
   routing protocol(s), and all applicable parameters [VPN IW]. 
    
   An essential pre-condition for an inter-AS VPN is an agreement 
   between the ASs involved that spells out at least trust, economic, 
   and management responsibilities.   
    
   The overall scalability of the VPN service MUST allow the L3VPN 
   service to be offered across potentially hundreds of SPs, with the 
   overall scaling parameters per SP given in [PPVPN-GR]. 
    
   6.10.1 Routing Protocols 
   If the link between ASs is not trusted, routing protocols running 
   between those ASs MUST support some form of authentication. For 
   example, the TCP option for carrying an MD5 digest may be used to 
   enhance security for BGP [RFC2385].  
    
   BGP MUST be supported as the standard inter-AS routing protocol to 
   control the path taken by L3VPN traffic. 
    
   6.10.2 Management 
   The general requirements for managing a single AS apply to a 
   concatenation of ASs. A minimum subset of such capabilities is the 
   following: 
     - Diagnostic tools (e.g., ping, traceroute) 
     - Secured access to one AS management system by another 
    
   Carugi, McDysan et al Informational - Expires January 2005      28 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
     - Configuration request and status query tools 
     - Fault notification and trouble tracking tools 
    
   6.10.3 Bandwidth and QoS Brokering 
   When a VPN spans multiple ASs, there is a desire for a brokering 
   mechanism that requests certain SLA parameters, such as bandwidth 
   and QoS, from the other domains and/or networks involved in 
   transferring traffic to various sites. Although bandwidth and QoS 
   brokering across multiple ASs is not common in today's networks, 
   these may be desirable in order to maintain SLAs in inter-AS VPNs. 
   This section describes requirements for features that would 
   facilitate these mechanisms. The objective is that a solution SHOULD 
   be able to determine whether a set of ASs can establish and 
   guarantee uniform QoS in support of a L3VPN. 
    
   The brokering mechanism can be a manual one, for example, where one 
   provider requests from another provider a specific set of bandwidth 
   and QoS parameters for traffic going to and from a specific set of 
   sites. The mechanism could also be an automated one where a device 
   dynamically requests and receives certain bandwidth and SLA/QoS 
   parameters. For instance, in the case of a L3 VPN over MPLS, a PE 
   may negotiate the label for different traffic classes to reach a PE 
   residing in a neighboring AS. Or, it might be a combination of both. 
   For additional detailed requirements on the automated approach, see 
   [TE-INTERAS]. 
 
   It is not desirable to perform brokering on a per VPN basis since 
   such an approach would not scale. A solution MUST provide some means 
   of aggregating QoS and bandwidth brokering requests between ASs. One 
   method could be for SP's to make an agreement specifying the maximum 
   amount of bandwidth for specific QoS parameters for all VPN 
   customers using the SP network. Alternatively, such aggregation 
   might be on a per hierarchical tunnel basis between PE routers in 
   different ASs supporting a L3 VPN service [TE-INTERAS].  
    
   6.10.4 Security Considerations 
   If a tunnel traverses multiple SP networks and it passes through an 
   unsecured SP, POP, NAP, or IX, then security mechanisms MUST be 
   employed. These security mechanisms include encryption, 
   authentication and resource protection as described in section 6.9 
   and security management of section 7.5. For example, a provider 
   should consider use of both authentication and encryption for a 
   tunnel used as part of a L3VPN that traverses another service 
   provider's network. 
    
   6.11  L3VPN Wholesale 
   The architecture MUST support the possibility of one service 
   provider offering VPN service to another service provider.  Another 
   example is when one service provider sells L3VPN service at 
   wholesale to another service provider, who then resells that VPN 
   service to his or her customers.  
    
    
   Carugi, McDysan et al Informational - Expires January 2005      29 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   The wholesaler's VPN MUST be transparent to the addressing and 
   routing used by the reseller. 
    
   Support for additional levels of hierarchy, for example three levels 
   where a reseller can again resell the VPN service to yet another VPN 
   provider, SHOULD be provided.  
    
   The Carrier's Carrier scenario is the name used in this document for 
   this category of L3VPN wholesale (although some scenarios of Inter-
   AS/Inter-Provider VPN could possibly fall in this L3VPN wholesale 
   category too). Various carrier's carrier scenarios should be 
   supported, such as: 
  - the customer Carriers do not operate L3VPN services for their 
     clients;  
  - the customer Carriers operate L3VPN services for their clients, 
     but these services are not linked with the L3VPN service offered 
     by the Carrier's Carrier;  
  - the customer Carriers operate L3VPN services for their clients and 
     these services are linked with the L3VPN service offered by the 
     Carrier's Carrier ("Hierarchical VPNs" scenario) 
    
   6.12  Tunneling Requirements 
   Connectivity between CE sites or PE devices in the backbone SHOULD 
   be able to use a range of tunneling technologies, such as L2TP, 
   IPSEC, GRE, IP-in-IP, MPLS, etc. 
    
   To set up tunnels between routers, every router MUST support static 
   configuration for tunneling and MAY support a tunnel setup protocol. 
   If employed, a tunnel establishment protocol SHOULD be capable of 
   conveying information, such as the following: 
     - Relevant identifiers  
     - QoS/SLA parameters 
     - Restoration parameters 
     - Multiplexing identifiers 
     - Security parameters 
    
   There MUST be a means to monitor the following aspects of tunnels: 
     - Statistics, such as amount of time spent in the up and down 
      state 
     - Count of transitions between the up and down state 
     - Events, such as transitions between the up and down states 
    
   The tunneling technology used by the VPN Service Provider and its 
   associated mechanisms for tunnel establishment, multiplexing, and 
   maintenance MUST meet the requirements on scaling, isolation, 
   security, QoS, manageability, etc. 
    
   6.13  Support for Access and Backbone Technologies 
   This section describes requirements for aspects of access and 
   backbone network technologies from an SP point of view. 
    


    
   Carugi, McDysan et al Informational - Expires January 2005      30 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   Some SPs MAY desire that a single network infrastructure should 
   suffice for all services, public IP, VPNs, traffic engineering, and 
   differentiated services [L2 VPN]. 
    
   6.13.1 Dedicated Access Networks 
   Ideally, the L3VPN service SHOULD be independent of physical, link 
   layer or even network technology of the access network. However, the 
   characteristics of access networks MUST be accounted for when 
   specifying the QoS aspects of SLAs for VPN service offerings. 
    
   6.13.2 On-Demand Access Networks  
   Service providers SHOULD be able to support temporary user access, 
   as described in section 5.11.2 using dedicated or dial-in access 
   network technology.   
    
   L3VPN solutions MUST support the case where a VPN user directly 
   accesses the VPN service through an access network connected to the 
   service provider. They MUST also describe how they can support the 
   case where one or more other service provider networks are used as 
   access to the service provider supporting the L3VPN service.  
    
   Ideally, all information necessary to identify and authenticate 
   users for an intranet SHOULD be stored and maintained by the 
   customer. In an extranet, one customer SHOULD be able to maintain 
   the authentication server, or the customers involved in the extranet 
   MAY choose to outsource the function to a service provider. 
    
   Identification and authentication information could be made 
   available to the service provider for controlling access, or the 
   service provider may query a customer maintained server. 
   Furthermore, one SP may act as access for the SP providing the VPN 
   service. In the case where the access SP performs identification and 
   authentication on behalf of the VPN SP, an agreement MUST be reached 
   on a common specification. 
    
   Support for at least the following authentication protocols SHALL be 
   supported: PAP, CHAP and EAP, since they are currently used in a 
   wide range of equipment and services. 
    
   6.13.3 Backbone Networks 
   Ideally, the backbone interconnecting SP PE and P devices SHOULD be 
   independent of physical and link layer technology. Nevertheless, the 
   characteristics of backbone technology MUST be taken into account 
   when specifying the QoS aspects of SLAs for VPN service offerings. 
    
   6.14  Protection, Restoration 
   When primary and secondary access connections are available, a L3VPN 
   solution MUST provide restoration of access connectivity whenever 
   the primary access link from a CE site to a PE fails. This 
   restoration capability SHOULD be as automatic as possible, that is, 
   the traffic should be directed over the secondary link soon after 
   failure of the primary access link is detected. Furthermore, 
    
   Carugi, McDysan et al Informational - Expires January 2005      31 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   reversion to the primary link SHOULD be dynamic, if configured to do 
   so [VPN-NEEDS]. 
    
   As mentioned in Section 5.11.4 above, in the case of multi-homing, 
   the load balancing capability MAY be used to achieve a degree of 
   redundancy in the network. In the case of failure of one or more 
   (but not all) of the multi-homed links, the load balancing 
   parameters MAY be dynamically adjusted to rapidly redirect the 
   traffic from the failed link(s) to the surviving links. Once the 
   failed link(s) is (are) restored, the original provisioned load 
   balancing ratio SHOULD be restored to its value prior to the 
   failure. 
    
   An SP SHOULD be able to deploy protection and restoration mechanisms 
   within his or her backbone infrastructure to increase reliability 
   and fault tolerance of the VPN service offering. These techniques 
   SHOULD be scalable, and therefore should strive to not perform such 
   function in the backbone on a per-VPN basis.  
    
   Appropriate measurements and alarms that indicate how well network 
   protection and restoration mechanisms are performing MUST be 
   supported.  
    
   6.15  Interoperability 
   Service providers are interested in interoperability in at least the 
   following scenarios: 
     - To facilitate use of PE and managed CE devices within a single SP 
     network 
     - To implement L3VPN services across two or more interconnected SP 
     networks 
     - To achieve interworking or interconnection between customer sites 
     using different L3VPN approaches or different implementations of 
     the same approach  
 
   Each approach MUST describe whether any of the above objectives can 
   be met. If an objective can be met, the approach MUST describe how 
   such interoperability could be achieved. In particular, the approach 
   MUST describe the inter-solution network interface, encapsulation 
   method(s), routing protocol(s), security, isolation, management, and 
   all other applicable aspects of the overall VPN solution provided 
   [VPN IW].  
 
   6.16  Migration Support 
   Service providers MUST have a graceful means to migrate a customer 
   with minimal service disruption on a site-by-site basis to a L3VPN 
   approach.  
 
   If L3VPN approaches can interwork or interconnect, then service 
   providers MUST have a graceful means to migrate a customer with 
   minimal service disruption on a site-by-site basis whenever changing 
   interworking or interconnection. 
 
    
   Carugi, McDysan et al Informational - Expires January 2005      32 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   7 Service Provider Management Requirements 
   A service provider MUST have a means to view the topology, 
   operational state, order status, and other parameters associated 
   with each customer's VPN. Furthermore, an SP MUST have a means to 
   view the underlying logical and physical topology, operational 
   state, provisioning status, and other parameters associated with the 
   equipment providing the VPN service(s) to its customers. 
    
   Currently, proprietary methods are often used to manage VPNs. The 
   additional expense associated with operators having to use multiple 
   proprietary management methods (e.g., command line interface (CLI) 
   languages) to access such systems is undesirable. Therefore, devices 
   SHOULD provide standards-based interfaces wherever feasible. 
    
   The remainder of this section presents detailed SP management 
   requirements for a Network Management System (NMS) in the 
   traditional fault, configuration, accounting, performance, and 
   security (FCAPS) management categories. Much of this text was 
   adapted from ITU-T Y.1311.1. 
    
   7.1 Fault management  
   Support for fault management includes: 
   - indication of customers impacted by failure, 
   - fault detection (incidents reports, alarms, failure 
   visualization), 
   - fault localization (analysis of alarms reports, diagnostics), 
   - incident recording or logs, creation and follow through of trouble 
   tickets), 
   - corrective actions (traffic, routing, resource allocation). 
    
   Since PE-based VPNs rely on a common network infrastructure, the NMS 
   MUST provide a means to inform the provider on the VPN customers 
   impacted by a failure in the infrastructure. The NMS SHOULD provide 
   pointers to the related customer configuration information to aid in 
   fault isolation and the determination of corrective action. 
    
   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). This is  a 
   likely case of compromised security [VPNSEC]. Detection of such 
   errors is inherently difficult because the problem involves more 
   than one node and may reach across a global perspective. One 
   approach could be a protocol that systematically checks that all 
   constraints and consistency checks hold among tunnel configuration 
   parameters at the various end points.  
    
   A capability to verify L3 reachability within a VPN MUST be provided 
   for diagnostic purposes.   
    
   A capability to verify the parameter configuration of a device 
   supporting a L3VPN MUST be provided for diagnostic purposes.   
    
    
   Carugi, McDysan et al Informational - Expires January 2005      33 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   7.2 Configuration Management 
   Overall, the NMS must support configuration necessary to realize 
   desired L3 reachability of a L3VPN. Toward this end, an NMS 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 shared access to 
   the Internet is provided, then this option MUST also be 
   configurable. 
    
   Since VPN configuration and topology are highly dependent upon a 
   customer's organization, provisioning systems MUST address a broad 
   range of customer specific requirements. The NMS MUST ensure that 
   these devices and protocols are provisioned consistently and 
   correctly. 
    
   Provisioning for adding or removing sites SHOULD be as localized and 
   automated as possible. 
    
   Configuration management for VPNs, according to service templates 
   defined by the provider MUST be supported. A service template 
   contains fields which, when instantiated, yield a definite service 
   requirement or policy. For example, a template for an IPSec tunnel 
   would contain fields such as tunnel end points, authentication 
   modes, encryption and authentication algorithms, pre-shared keys if 
   any, and traffic filters. An SLA template would contain fields such 
   as delay, jitter, throughput and packet loss thresholds as well as 
   end points over which the SLA has to be satisfied. In general, a 
   customer's service order can be regarded as a set of instantiated 
   service templates. This set can, in turn, be regarded as the logical 
   or service architecture of the customer's VPN. 
    
   Service templates can also be used by the provider to define the 
   service architecture of the provider's own network. For example, 
   OSPF templates could contain fields such as the subnets that form a 
   particular area, the area identifier and the area type. BGP service 
   template could contain fields which when instantiated would yield a 
   BGP policy, such as for expressing a preference about an exit router 
   for a particular destination. 
    
   The set of service templates SHOULD be comprehensive in that they 
   can capture all service orders in some meaningful sense. 
    
   The provider SHOULD provide means for translating instantiated 
   service templates into device configurations so that associated 
   services can be provisioned.  
    
   Finally, the approach SHOULD provide 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. 
    
    
   Carugi, McDysan et al Informational - Expires January 2005      34 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   7.2.1 Configuration Management for PE-Based VPNs 
   Requirements for configuration management unique to a PE-based VPN 
   are as follows. 
 
   o The NMS MUST support configuration of at least the following 
   aspects of a L3 PE routers: intranet and extranet membership, CE 
   routing protocol for each access connection, routing metrics, 
   tunnels, etc.  
    
   o The NMS SHOULD use identifiers for SPs, L3VPNs, PEs, CEs, 
   hierarchical tunnels and access connections as described in section 
   6.3. 
    
   o Tunnels MUST be configured between PE and P devices.  This 
   requires coordination of identifiers of tunnels, hierarchical 
   tunnels, VPNs, and any associated service information, for example a 
   QoS/SLA service. 
    
   o Routing protocols running between PE routers and CE devices MUST 
   be configured per VPN.   
    
   O For multicast service, multicast routing protocols MUST also be 
   configurable. 
    
   o Routing protocols running between PE routers and between PE and P 
   routers MUST also be configured.   
    
   o 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. 
    
   7.2.2 Configuration management for CE-based VPN 
   Requirements for configuration management unique to a CE-based VPN 
   are as follows. 
    
   o Tunnels MUST be configured between CE devices.  This requires 
   coordination of identifiers of tunnels, VPNs, and any associated 
   service information, for example, a QoS/SLA service. 
    
   o Routing protocols running between PE routers and CE devices MUST 
   be configured.  For multicast service, multicast routing protocols 
   MUST also be configurable. 
    
   7.2.3 Provisioning Routing  
   A means for a service provider to provision parameters for the IGP 
   for a L3VPN MUST be provided. This includes link level metrics, 
   capacity, QoS capability, and restoration parameters. 
    
   7.2.4 Provisioning Network Access 
   A service provider MUST have the means to provision network access 
   between SP-managed PE and CE, as well as the case where the customer 
   manages the CE. 
    
   Carugi, McDysan et al Informational - Expires January 2005      35 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
 
   7.2.5 Provisioning Security Services 
   When a security service is requested, an SP MUST have the means to 
   provision the entities and associated parameters involved with the 
   service. For example, for IPsec service, tunnels, options, keys, and 
   other parameters must be provisioned at either the CE and/or PE. In 
   the case of an intrusion detection service, the filtering and 
   detection rules must be provisioned on a VPN basis. 
    
   7.2.6 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 provisionable. 
    
   Dynamic VPN resource assignment is crucial to cope with the frequent 
   changes requests from customer's (e.g., sites joining or leaving a 
   VPN), as well as to achieve scalability. The PEs SHOULD be able to 
   dynamically assign the VPN resources. This capability is especially 
   important for dial and wireless VPN services. 
    
   If an 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 Agreement 
   (SLA). Examples of SLA parameters are response time and probability 
   of being able to service such a request.  
    
   7.2.7 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 protection, 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 the VPN in order to solve issues such as addressing, 
   integrity and security. 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 standard IP services, like DNS, NTP and RADIUS 
   needed for ordinary network operation and management. The provider 
   SHOULD be able to provide IP services to multiple VPN customers. 
    
   A firewall function MAY be required to restrict access to the L3VPN 
   from the Internet [Y.1311].  
    
   A managed firewall service MUST be carrier grade. For redundancy and 
   failure recovery, 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.  
    
    
   Carugi, McDysan et al Informational - Expires January 2005      36 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   Managed firewalls MUST be supported on a per-VPN basis, although 
   multiple VPNs may be supported by the same physical device (e.g., in 
   PE-based solution).  Managed firewalls SHOULD be provided at the 
   major access point(s) for the L3VPN. Managed firewall services may 
   be embedded in CE or PE device, or implemented in standalone 
   devices. 
    
   The NMS SHOULD allow a customer to outsource the management of an IP 
   networking service to the SP providing the VPN or to a third party.  
    
   The NMS SHOULD support collection of information necessary for 
   optimal allocation of IP services in response to customer orders. 
    
    
    
   Reachability to and from the Internet to sites within a VPN MUST be 
   configurable by an SP. This could be controlled by configuring 
   routing policy to control distribution of VPN routes advertised to 
   the Internet.  
    
   7.2.8 Provisioning Hybrid VPN Services  
   Configuration of interworking or interconnection between L3VPN 
   solutions SHOULD be also supported. Ensuring that security and end-
   to-end QoS issues are provided consistently SHOULD be addressed. 
    
   7.3 Accounting 
   Many service providers require collection of measurements regarding 
   resource usage for accounting purposes. The NMS MAY need 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 SLS is not met.  
    
   A L3VPN solution MUST describe how the following accounting 
   functions can be provided: 
   - measurements of resource utilization, 
   - collection of accounting information, 
   - storage and administration of measurements. 
    
   Some providers may require near-real time reporting of measurement 
   information, and may offer this as part of a customer network 
   management service. 
    
   If an SP supports a "Dynamic Bandwidth management" service, then the 
   dates, times, amounts and interval required to perform requested 
   bandwidth allocation change(s) MUST be traceable for monitoring and 
   accounting purposes. 
    
   Solutions should state compliance to accounting requirements, as 
   described in section 1.7 of RFC 2975. 
    



    
   Carugi, McDysan et al Informational - Expires January 2005      37 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   7.4 Performance Management  
   Performance management MUST support functions involved with 
   monitoring and collecting performance data regarding devices, 
   facilities, and services, as well as determination of conformance to 
   Service Level Specifications (SLS), such as QoS and availability 
   measurements. 
    
   Performance management SHOULD also support analysis of important 
   aspects of a L3VPN , such as bandwidth utilization, response time, 
   availability, QoS statistics, and trends based on collected data. 
    
   7.4.1 Performance Monitoring  
   The NMS MUST monitor device behavior to evaluate performance metrics 
   associated with an SLA. 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 NMS MUST also monitor aspects of the VPN not directly associated 
   with an SLA, such as resource utilization, state 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.  
    
   7.4.2 SLA and QoS management features  
   The NMS SHOULD support SLAs between an SP and the various VPN 
   customers according to the corresponding SLSes by measurement of the 
   indicators defined within the context of the SLA, on a regular 
   basis. 
    
   The NMS SHOULD use the QOS parameter measurement definitions, 
   techniques, and methods as defined by the IETF IP Performance 
   Metrics (IPPM) working group for delay, loss, and delay variation.  
    
   The NMS SHOULD support allocation and measurement of end-to-end QoS 
   requirements to QoS parameters for one or more VPN network(s). 
    
   Devices supporting L3VPN SLAs SHOULD have real-time performance 
   measurements that have indicators and threshold crossing alerts. 
   Such thresholds should be configurable.  
    
   7.5 Security Management 
   The security management function of the NMS MUST include management 
   features to guarantee the security of devices, access connections, 
   and protocols within the L3VPN network(s), as well as the security 
   of customer data and control as described in section 6.9.  
    
   7.5.1 Resource Access Control 
   Resource access control determines the privileges that a user has to 
   access particular applications and VPN network resources. Without 
   such control, only the security of the data and control traffic is 
    
   Carugi, McDysan et al Informational - Expires January 2005      38 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   protected, leaving the devices providing the L3VPN network 
   unprotected. Access control capabilities protect these devices to 
   ensure that users have access to only the resources and applications 
   to which they are authorized to use.  
    
   In particular, access to the routing and switching resources managed 
   by the SP MUST be tightly controlled to prevent and/or effectively 
   mitigate a malicious attack. More detailed requirements in this area 
   are described in [VPNSEC]. 
    
   7.5.2 Authentication  
   Authentication is the process of verifying that the sender is 
   actually who he or she claims to be. The NMS MUST support standard 
   methods for authenticating users attempting to access management 
   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. 
    
   Strong authentication schemes SHALL be supported to ensure the 
   security of both VPN access point-to-VPN access point  (e.g., PE to 
   PE in a PE-based case) and client-to-VPN Access point (e.g., CE-to-
   PE in a PE-based case) communications. This is particularly 
   important to prevent VPN access point spoofing.  VPN Access Point 
   Spoofing is the situation where an attacker tries to convince a PE 
   or CE that the attacker is the VPN Access Point.  If an attacker can 
   convince a PE or CE device of that, then that  device will send VPN 
   traffic to the attacker (who could forward it to the true access 
   point after compromising confidentiality or integrity).In other 
   words, a non-authenticated VPN AP can be spoofed with a man-in-the-
   middle attack, because the endpoints never verify each other.  A 
   weakly-authenticated VPN AP may be subject to such an attack. 
   Strongly-authenticated VPN APs are not subject to such attacks, 
   because the man-in-the-middle cannot be authenticated as the real 
   AP, due to the strong authentication algorithms. 
    
   7.6 Basis and Presentation Techniques of Management Information 
   Each L3VPN solution approach MUST specify the management information 
   bases (MIB) modules for the network elements involved in L3VPN 
   services. This is an essential requirement in network provisioning. 
   The approach SHOULD identify any information not contained in a 
   standard MIB related to FCAPS that is necessary to meet a generic 
   requirement. 
    
   An IP VPN (Policy)Information model, when available, SHOULD reuse 
   the policy  information models being developed in parallel for 
   specific IP    network capabilities [IM-REQ]. This includes the QoS 
   Policy Information Model_[QPIM] and the IPSEC Configuration Policy 
   Model_ [IPSECIM]. The IP VPN Information model SHOULD provide the 
   OSS with adequate "hooks" to correlate service level specifications 
    
   Carugi, McDysan et al Informational - Expires January 2005      39 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
   with traffic data collected from network elements. The use of 
   policies includes rules that control corrective actions taken by OSS 
   components responsible for monitoring the network and ensuring that 
   it meets service requirements. 
    
   Additional requirements on VPN information models are given in 
   reference [IM-PPVPN]. In particular, an information model MUST allow 
   an SP to change VPN network dimensions with minimal influence on 
   provisioning issues. The adopted model SHOULD be applicable to both 
   small/medium size and large-scale L3VPN scenarios.  
    
   Some service providers MAY require systems that visually, audibly, 
   or logically present FCAPS information to internal operators and/or 
   customers. 
    
   8 Security Considerations 
   Security considerations occur at several levels and dimensions 
   within L3 VPNs, as detailed within this document. This section 
   provides a summary with references to supporting detailed 
   information.  
    
   The requirements in this document separate the notion of traditional 
   security requirements, such as integrity, confidentiality, and 
   authentication from that of isolating (or separating) the exchange 
   of VPN data and control traffic  between specific sets of sites (as 
   defined in sections 3.3 and 4.1). Further detail on security 
   requirements is given from the customer and service provider 
   perspectives in sections 5.9 and 6.9, respectively. In an analogous 
   manner, further detail on data and control traffic isolation 
   requirements are given from the customer and service provider 
   perspectives in sections 5.1 and 6.8, respectively. Additionally, 
   references to a document [VPNSEC] specifically addressing security 
   requirements are made where appropriate. 
    
   Furthermore, requirements regarding management of security from a 
   service provider perspective are described in section 7.5. 
    
   9 Acknowledgements 
   The authors of this document would like to acknowledge the 
   contributions from the people who launched the work on VPN 
   requirements inside ITU-T SG13, the authors of the original IP VPN 
   requirements and framework document [RFC 2764], as well as Tom 
   Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, 
   Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le 
   Garrec. The authors are also grateful to the helpful suggestions and 
   direction provided by the technical advisors, Alex Zinin, Scott 
   Bradner, Bert Wijnen and Rob Coltun. Finally, the authors also wish  
   to acknowledge the insights and requirements gleaned from the many 
   documents listed in the references section. Citations to these 
   documents were made only where the authors believed that additional 
   insight to the requirement could be obtained by reading the source 
   document. 
    
   Carugi, McDysan et al Informational - Expires January 2005      40 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
          
   10 References 
    
    
    
   10.1  Normative References 
    [RFC 3809]     Nagarajan, A., "Generic Requirements for Provider 
                   Provisioned VPN," Work in Progress. 
    [RFC 3377]     Hodges, J., Morgan, R. "Lightweight Directory Access 
                   Protocol (v3): Technical Specification," RFC 3377,  
                   September 2002  
    [RFC 1918]     Rekhter, Y., et al., "Address Allocation for Private    
                   Internets," RFC 1918, February 1996. 
    [RFC 2026]     Bradner, S., "The Internet Standards Process --  
                   Revision 3", BCP 9, RFC 2026, October 1996.   
    [RFC 2119]     Bradner, S., "Key words for use in RFCs to Indicate 
                   Requirement Levels", BCP 14, RFC 2119, March 1997 
    [RFC 2205]     Braden, R., Ed., Zhang, L., Berson, S.,  Herzog, S., 
                   Jamin, S. "Resource ReSerVation Protocol (RSVP) -- 
                   Version 1 Functional Specification," September 1997. 
    [RFC 2211]     Wroclawski, J., Specification of the Controlled-Load 
                   Network Element Service, RFC 2211, IETF, September 
                   1997. 
    [RFC 2212]     Shenker, S., Partridge, C., Guerin, R., Specification 
                   of Guaranteed Quality of Service, RFC 2212, IETF, 
                   September 1997. 
    [RFC 2251]     Wahl, M. et al., "Lightweight Directory Access 
                   Protocol (v3)," RFC 2251, December 1997. 
    [RFC 2475]     Blake, S., Black, D., Carlson, M., Davies, E., Wang, 
                   Z., Weiss, W.  "An Architecture for Differentiated 
                   Services", RFC  2475, Dec. 1998. 
    [RFC 2597]     Baker, F., Heinanen, J., Weiss, W., Wroclawski, J. 
                   "Assured Forwarding PHB Group", RFC 2597, June 1999.  
    [RFC 2661]     Townsley, W. et al., "Layer Two Tunneling Protocol 
                   "L2TP"," RFC 2661, August 1999. 
    [RFC 2685]     Fox B., et al, "Virtual Private Networks Identifier", 
                   RFC 2685, September 1999. 
    [RFC 2983]     Black, D. "Differentiated Services and Tunnels," 
                   RFC2983, October 2000 
    [RFC 3031]     Rosen, E., Viswanathan, A., Callon, R.  "Multiprotocol 
                   Label Switching Architecture," January 2001. 
    [RFC 3246]     Davie, B., et al., "An Expedited Forwarding PHB", RFC 
                   3246, March 2002. 
    [RFC 3270]     Le Faucheur, F., et al., "Multi-Protocol Label 
                   Switching (MPLS) Support of Differentiated Services," 
                   RFC 3270, May 2002 
    
   10.2  Non-normative References 
    [2547bis]      Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work 
                   in progress. 
    [2917bis]      Muthukrishnan, K., et al., "A Core MPLS IP VPN 
                   Architecture," work in progress   
    
   Carugi, McDysan et al Informational - Expires January 2005      41 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
    [DOCSIS 1.1]   Data Over Cable Service Interface Specification 
                   (DOCSIS), Cable Labs, 
                   http://www.cablemodem.com/specifications.html 
    [FRF.13]       Frame Relay Forum, "Service Level Definitions 
                   Implementation Agreement," August, 1998. 
    [IM-PPVPN]     Lago, P., et al., "An Information Model for Provider 
                   Provisioned Virtual Private Networks," work in 
                   progress.  
    [IM-REQ]       Iyer, M., et al., "Requirements for an IP VPN Policy 
                   Information Model," work in progress 
    [IPSECIM]      Jason, J., "IPsec Configuration Policy Model," work 
                   in progress.  
    [CE-PPVPN]     De Clercq, J., Paridaens, O., Krywaniuk, A., Wang, 
                   C., "An Architecture for Provider Provisioned CE-
                   based Virtual Private Networks using IPsec," work in 
                   progress 
    [IPSEC-PPVPN]  Gleeson, B., "Uses of IPsec with Provider 
                   Provisioned VPNs," work in progress.     
    [L2 MPLS]      Martini, L., et al., "Transport of Layer 2 Frames 
                   Over MPLS," work in progress. 
    [L2 VPN]       Rosen, E., et al., "An Architecture for L2VPNs," 
                   work in progress. 
    [L2 VPN]       Kompella, K., Bonica, R., "Whither Layer 2 VPNs?," 
                   work in progress. 
    [MPLS SEC]     Behringer, M., "Analysis of the Security of the MPLS 
                   Architecture," work in progress 
    [PPVPN-TERM]   Andersson, L., Madsen, T., "PPVPN Terminology," work 
                   in progress 
    [L3VPN-SEC]    Fang, L., et al., "Security Framework for Provider 
                   Provisioned Virtual Private Networks," work in 
                   progress. 
    [NBVPN-FR]     Suzuki, M. and Sumimoto, J. (editors), "A framework 
                   for Network-based VPNs", work in progress  
    [L3VPN-FR]     Callon, R., Suzuki, M., et al. "A Framework for 
                   Layer 3 Provider Provisioned Virtual Private 
                   Networks ",work in progress 
    [PPVPN-VR]     Knight, P., Ould-Brahim, H., Gleeson, B., "Network 
                   based IP VPN  Architecture  using  Virtual  
                   Routers,"  work in progress 
    [QPIM]         Snir, Ramberg, Strassner, Cohen and Moore, "Policy 
                   QoS Information Model," work in progress. 
    [RFC 2547]     Rosen, E., Rekhter, Y., "BGP/MPLS VPNs," RFC 2547, 
                   March 1999.  
    [RFC 2764]     Gleeson, B., et al., "A Framework for IP based Virtual 
                   Private Networks", RFC 2764, February 2000. 
    [RFC 2975]     Aboba, B., et al., "Introduction to Accounting 
                   Management," October 2000. 
    [RFC 3198]     Westerinen, A., et al., "Terminology for Policy-Based 
                   Management," November, 2001. 
    [TE-INTERAS]   Zhang, R., Vasssuer, J.P., "MPLS Inter-AS Traffic 
                   Engineering requirements," work in progress. 
    [VPN DISC]     Squire, M. et al., "VPN Discovery Discussions and 
    
   Carugi, McDysan et al Informational - Expires January 2005      42 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
                   Options," work in progress. 
    [VPN IW]       Kurakami, H., et al., "Provider-Provisioned VPNs 
                   Interworking," work in progress. 
    [VPN SEC]      De Clercq, J., et al., "Considerations about 
                   possible security extensions to BGP/MPLS VPN," work 
                   in progress. 
    [VPN TUNNEL]   Worster, T., et al., "A PPVPN Layer Separation: VPN 
                   Tunnels and Core Connectivity," work in progress 
    [VPN-CRIT]     Yu, J., Jou, L., Matthews, A ., Srinivasan, V., 
                   "Criteria for Evaluating VPN Implementation 
                   Mechanisms", work in progress 
    [VPN-NEEDS]    Jacquenet, C., "Functional needs for the deployment 
                   of an IP VPN service offering : a service provider 
                   perspective ", work in progress 
    [Y.1241]       "IP Transfer Capability for the support of IP based 
                   Services", Y.1241 ITU-T  Recommendation, January 
                   2001. 
    [Y.1311.1]     Carugi, M. (editor), "Network Based IP VPN over MPLS 
                   architecture",Y.1311.1 ITU-T Recommendation, 
                   July2001.  
    [Y.1311]       Knightson, K. (editor), "Network based VPNs  - 
                   Generic Architecture and Service Requirements," 
                   Y.1311 ITU-T Recommendation, March 2002.   
          
   11 Authors' address 
    
   Marco Carugi (Co-editor) 
   Nortel Networks  
   Parc d'activit‰s de Magny-Les Jeunes Bois  CHATEAUFORT  
   78928 YVELINES Cedex 9  - FRANCE   
   EMail: marco.carugi@nortelnetworks.com  
    
   Dave McDysan (Co-editor) 
   MCI 
   22001 Loudoun County Parkway 
   Ashburn, VA 20147, USA 
   EMail: dave.mcdysan@mci.com 
    
   Luyuan Fang 
   AT&T 
   200 Laurel Ave - Room C2-3B35 
   Middletown, NJ 07748 USA 
   EMail: Luyuanfang@att.com 
    
   Ananth Nagarajan 
   Juniper Networks 
   EMail: ananth@juniper.net 
    
   Junichi Sumimoto 
   NTT Communications Corporation 
   3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan 
   EMail: j.sumimoto@ntt.com 
    
   Carugi, McDysan et al Informational - Expires January 2005      43 
 
               Service requirements for Layer 3 PPVPNs      July 2004 
 
 
    
   Rick Wilder 
   Alcatel 
   EMail: rick.wilder@alcatel.com 
    
    
   Full copyright statement 
    
   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist its implementation may be prepared, copied, published and 
   distributed, in whole or in part, without restriction of any kind, 
   provided that the above copyright notice and this paragraph are 
   included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 




















    
   Carugi, McDysan et al Informational - Expires January 2005      44