[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

   INTERNET DRAFT                                             M. Carugi
   Internet Engineering Task Force                       France Telecom
   Document:                                                 D. McDysan
   draft-ietf-ppvpn-requirements-04.txt                        WorldCom
   March 2002                                              (Co-Editors)
   Category: Informational                                      L. Fang
   Expires: September 2002                                         AT&T
                                                           F. Johansson
                                                                  Telia
                                                       Ananth Nagarajan
                                                                 Sprint
                                                            J. Sumimoto
                                                                    NTT
                                                              R. Wilder
                                                                Masergy


   Service requirements for Layer 3 Provider Provisioned Virtual Private
   Networks:
   <draft-ietf-ppvpn-requirements-04.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 Provider Provisioned Virtual
   Private Network (ppvpn) working group. Comments should be addressed
   to WG's mailing list at ppvpn@ppvpn.francetelecom.com. The charter
   for ppvpn may be found at http://www.ietf.org/html.charters/ppvpn-
   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 Provider Provisioned
   Virtual Private Networks (PPVPNs). It identifies requirements
Carugi et al                                                         1                Service requirements for Layer 3 PPVPNs     March, 2002


   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.

   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  Definitions .......................................................6
 2.1  Virtual Private Network Components .............................6
 2.2  Users, Sites, Customers and Agents .............................6
 2.3  Intranets, Extranets, and VPNs .................................7
 2.4  Networks of Customer and Provider Devices ......................7
 2.5  Access Networks, Tunnels, and Hierarchical Tunnels .............8
 2.6  Layer 3 VPNs and Virtual Forwarding Instances ..................8
 2.7  Customer and Provider Network Management ......................10
 2.8  Taxonomy for L3 PPVPN Types ...................................10
3  General Service Requirements .....................................11
 3.1  Traffic Types .................................................11
 3.2  Topology ......................................................11
 3.3  Isolated Exchange of Data and Routing Information .............11
 3.4  Security ......................................................12
   3.4.1   User data security .......................................12
   3.4.2   Access control ...........................................12
   3.4.3   Site authentication and authorization ....................12
 3.5  Addressing ....................................................12
 3.6  Quality of Service ............................................13
   3.6.1   QoS Standards ............................................13
   3.6.2   Service Models ...........................................14
 3.7  Service Level Specification and Agreements ....................15
 3.8  Management ....................................................16
 3.9  Interoperability ..............................................16
 3.10 Interworking ..................................................17
4  Customer Requirements ............................................17
 4.1  VPN Membership (Intranet/Extranet) ............................17
 4.2  Service Provider Independence .................................17
 4.3  Addressing ....................................................17
 4.4  Routing Protocol Support ......................................18
 4.5  Quality of Service and Traffic Parameters .....................18
   4.5.1   Application Level QoS Objectives .........................18
   4.5.2   DSCP Transparency ........................................18

Carugi et al    Informational - Expires September 2002               2                Service requirements for Layer 3 PPVPNs     March, 2002


 4.6  Service Level Specification/Agreement .........................19
 4.7  Customer Management of a VPN ..................................19
 4.8  Isolation .....................................................19
 4.9  Security ......................................................19
 4.10 Migration Impact ..............................................20
 4.11 Network Access ................................................20
   4.11.1  Physical/Link Layer Technology ...........................20
   4.11.2  Temporary Access .........................................21
   4.11.3  Sharing of the Access Network ............................21
   4.11.4  Access Connectivity ......................................21
 4.12 Service Access ................................................23
   4.12.1  Internet Access ..........................................23
   4.12.2  Hosting, Application Service Provider ....................23
   4.12.3  Other Services ...........................................23
 4.13 Hybrid VPN Service Scenarios ..................................24
5  Service Provider Network Requirements ............................24
 5.1  Scalability ...................................................24
   5.1.1   Service Provider Capacity Sizing Projections .............24
   5.1.2   Solution-Specific Metrics ................................25
 5.2  Addressing ....................................................25
 5.3  Identifiers ...................................................26
 5.4  Learning VPN Related Information ..............................26
 5.5  SLA and SLS Support ...........................................27
 5.6  Quality of Service (QoS) and Traffic Engineering ..............27
 5.7  Routing .......................................................27
 5.8  Isolation of Traffic and Routing ..............................28
 5.9  Security ......................................................29
   5.9.1   Support for Securing Customer Flows ......................29
   5.9.2   Authentication Services ..................................30
   5.9.3   Resource Protection ......................................30
 5.10 Inter-AS (SP)VPNs .............................................31
   5.10.1  Routing Protocols ........................................31
   5.10.2  Management ...............................................31
   5.10.3  Bandwidth and Qos Brokering ..............................32
   5.10.4  Security Considerations ..................................32
 5.11 PPVPN Wholesale ...............................................32
 5.12 Tunneling Requirements ........................................33
 5.13 Support for Access and Backbone Technologies ..................33
   5.13.1  Dedicated Access Networks ................................33
   5.13.2  On-Demand Access Networks ................................34
   5.13.3  Backbone Networks ........................................34
 5.14 Protection, Restoration .......................................34
 5.15 Interoperability ..............................................35
 5.16 Migration Support .............................................35
6  Service Provider Management Requirements .........................35
 6.1  Fault management ..............................................36
 6.2  Configuration Management ......................................36
   6.2.1   Configuration Management for PE-Based VPNs ...............37
   6.2.2   Configuration management for CE-based VPN ................38
   6.2.3   Provisioning Routing .....................................38
   6.2.4   Provisioning Network Access ..............................38
   6.2.5   Provisioning Security Services ...........................38

Carugi et al    Informational - Expires September 2002               3                Service requirements for Layer 3 PPVPNs     March, 2002


   6.2.6   Provisioning VPN Resource Parameters .....................39
   6.2.7   Provisioning Value-Added Service Access ..................39
   6.2.8   Provisioning Hybrid VPN Services .........................40
 6.3  Accounting ....................................................40
 6.4  Performance Management ........................................41
   6.4.1   Performance Monitoring ...................................41
   6.4.2   SLA and QoS management features ..........................41
 6.5  Security Management ...........................................41
   6.5.1   Management Access Control ................................42
   6.5.2   Authentication ...........................................42
 6.6  Network Management Techniques .................................42
7  Security Considerations ..........................................43
8  Acknowledgements .................................................43
9  References .......................................................44
10   Authors' address................................................46






































Carugi et al    Informational - Expires September 2002               4                Service requirements for Layer 3 PPVPNs     March, 2002



1 Introduction
   This section describes the scope and outline of the document.

1.1 Scope of this document
   This document provides requirements for Layer 3 Provider Provisioned
   Virtual Private Networks (ppvpn). It 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. The
   document states requirements from a general point of view, as well as
   from a customer and service provider point of view. The content of
   this document makes use of the terminologies and common components
   for deploying Layer 3 PPVPNs defined in [PPVPN-FR].  Unless otherwise
   stated, the term "PPVPN" used in this document specifically refers to
   Layer 3 PPVPNs, and Layer 2 PPVPN requirements are not included here.

   The specification of any technical means to provide PPVPN services is
   outside the scope of this document. Other documents, such as the
   framework document [PPVPN-FR] and several sets of documents, one set
   per each individual technical approach providing PPVPN services, are
   intended to cover this aspect.

   This document discusses two types of PPVPNs: BGP-VPNs (e.g. RFC 2547)
   and virtual routers.  Requirements for port-based VPNs (i.e., where
   the SP provides a Layer 2 interface, such as Frame Relay ATM, or
   Ethernet to the VPN customer, while using IP-based mechanisms in the
   provider infrastructure to improve scalability and configurability
   over traditional L2 networks)will be collected in other documents.
   The approach followed in this document distinguishes PPVPN types as
   to where the endpoints of tunnels exist. Terminology regarding
   whether equipment faces a customer or the service provider network is
   used to define the various types of PPVPN solutions.

   This document does not map requirements to each individual approach.
   Rather, it's intended use is as a "checklist" of requirements that
   will provide a consistent way to evaluate and document how well each
   individual approach satisfies specific requirements. The relevant
   documents for each individual approach should document the results of
   this evaluation.

   This document provides requirements from several points of view. It
   begins with the general, followed by a customer perspective, and
   concludes with specific needs of a Service Provider (SP). These
   requirements provide high-level PPVPN features expected by an SP in
   provisioning PPVPN to make them beneficial to his customers. These
   general 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.




Carugi et al    Informational - Expires September 2002               5                Service requirements for Layer 3 PPVPNs     March, 2002


1.2 Outline
   The outline of the rest of this document is as follows. Section 2
   defines terminology. Section 3 provides general requirements that
   apply to both customer and service providers. Section 4 states
   requirements from a customer perspective. Section 5 states network
   requirements from a service provider perspective. Section 6 states
   service provider management requirements. Section 7 describes
   security considerations. Section 8 lists acknowledgements. Section 9
   provides a list of references cited herein. Section 10 lists the
   author's addresses.

2 Definitions
   This section provides the definition of terms and concepts used
   throughout the document.

2.1 Virtual Private Network Components
   This document uses the word _private_ in VPN in the sense of
   ownership, which is different from the use of the similar word
   _privacy_ used in discussions regarding security. The term _virtual
   private_ means that the offered service retains at least some aspects
   of a privately owned customer network.

   The term "Virtual Private Network" (VPN) refers to the communication
   between a set of sites, making use of a shared network
   infrastructure. Multiple sites of a private network may therefore
   communicate via the public infrastructure, in order to facilitate the
   operation of the private network. The logical structure of the VPN,
   such as topology, addressing, connectivity, reachability, and access
   control, is equivalent to part of or all of a conventional private
   network using private facilities.

   The term _Provider Provisioned VPN_ refers to VPNs for which the
   service provider participates in management and provisioning of the
   VPN.

2.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 IP reachability
   without use of a specific service provider network. A site may
   consist of a set of users that are in geographic proximity.  However,
   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 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.

Carugi et al    Informational - Expires September 2002               6                Service requirements for Layer 3 PPVPNs     March, 2002



2.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.

   Note that an intranet or extranet can exist across a single service
   provider network or across multiple service providers.

   Virtual Private Network (VPN): The term VPN is used within this
   document to refer 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.

2.4 Networks of Customer and Provider Devices
   Service provider PPVPNs are composed of the following types of
   devices.

   Customer Edge (CE) device: A CE device faces the users at a customer
   site that has an access connection to a PE device. It may be a router
   switching-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 PPVPN, 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 may be a router or a
   switching-router.

   The term switching-router (SR) is used in this document as a
   generalization of the Label Switching Router (LSR) term defined in
   RFC 3031. As described in the next section, MPLS is one of several
   tunneling techniques that may be used in a PPVPN, therefore, in this
   document the "Label" adjective is dropped, leaving only the more
   generic Switching Router (SR) terminology. The router part of the
   term applies since all PPVPN services are supported by a routing
   infrastructure. The switching term applies to L2 services or use of
   switching technologies (e.g., MPLS) in support of L3 services.



Carugi et al    Informational - Expires September 2002               7                Service requirements for Layer 3 PPVPNs     March, 2002


   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 devices, but does not have any direct attachment to
   CE devices or keeps a minimal amount of VPN state (preferably none).

   Service Provider (SP) network: An SP network is a set of
   interconnected PE and P devices administered by a single service
   provider.

2.5 Access Networks, Tunnels, and Hierarchical Tunnels
   VPNs are built between CEs using access networks, tunnels, and
   hierarchical tunnels.

   Access connection: An access connection provides connectivity between
   a CE and a PE. This includes PPP over dedicated physical circuits, as
   well as logical circuits, such as Ethernet, frame Relay or ATM, 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 [RFC2661]).

   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:
   MPLS, GRE, IPsec, and IP-in-IP tunnels.

   Hierarchical Tunnel: Encapsulating one tunnel within another forms a
   hierarchical tunnel. Note that the tunneling protocols need not be
   the same in a hierarchical tunnel. In the context of VPNs, a
   hierarchical tunnel is a logical association between two entities
   (e.g., a CE or PE switching-router or router) defined by the
   innermost tunnel protocol header in a hierarchical tunnel [VPN
   TUNNEL]. For reasons of efficiency, some VPN solutions use
   hierarchical tunnels between PE routers to reduce the number of
   tunnels seen by P routers in the backbone.


2.6 Layer 3 VPNs and Virtual Forwarding Instances
   In a 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.



Carugi et al    Informational - Expires September 2002               8                Service requirements for Layer 3 PPVPNs     March, 2002


   Virtual Forwarding Instance (VFI): In a 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 access connection to
   the CE to VFIs in other PEs supporting the same L3 VPN. The VFI
   includes the router information base and forwarding information base
   for a L3 VPN. A VFI enables router functions dedicated to serving a
   particular VPN.  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 2.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
   virtual switching/forwarding instance 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 2.1 PE Usage of Separate Tunnels to Support VPNs

   Figure 2.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. This method is
   preferable since it requires support for fewer tunnels by the P
   switching routers in a service provider backbone.














Carugi et al    Informational - Expires September 2002               9                Service requirements for Layer 3 PPVPNs     March, 2002


               +----------+                  +----------+
+-----+        |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 2.2 PE Usage of a Shared Hierarchical Tunnels to Support VPNs

2.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 also include confidential data, such
   as encryption keys. It may use a combination of proprietary network
   management system, SNMP manager, or directory service (e.g., LDAP
   [RFC1777] [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 customer
   network management 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 PPVPN service. It may use a combination of proprietary network
   management system, SNMP manager, or directory service (e.g., LDAP
   [RFC1777] [RFC2251]).

2.8 Taxonomy for L3 PPVPN Types
   The taxonomy of PPVPN types is primarily determined by whether the
   tunnels that provide the service either terminate on Customer Edge
   (CE), or on Provider Edge (PE) devices, as defined in section 2.4.

   A CE-based VPN is one in which knowledge of L3 aspects of the
   customer network is limited to CE devices. Customer sites are
   interconnected via tunnels or nested tunnels. The SP backbone is
   unaware of the existence of the VPN.

   A PE-based VPN is one in which the SP backbone is aware of (i.e.,
   maintains state information for) the VPN, and provides a layer 3


Carugi et al    Informational - Expires September 2002              10                Service requirements for Layer 3 PPVPNs     March, 2002


   service that routes packets between customer sites using the customer
   network's address space.

   A CE-based L3 VPN is a CE-based VPN where the service provided
   by the CE equipment to the customer sites is a network
   layer (i.e.,layer 3) service.

   A PE-based L3 VPN is one in which the SP backbone is aware
   of the VPN, and provides a layer 3 service that routes packets
   between customer sites using the customer network's address space.

   The Layer 3 PPVPN framework document [PPVPN-FR] further describes
   these concepts in the context of a reference model that defines
   layered service relationships between devices and one or more levels
   of tunnels.

3 General Service Requirements
   This section contains requirements that apply to both the customer
   and the provider, or are of an otherwise general nature.

3.1 Traffic Types
   PPVPN services must support unicast traffic and should support
   multicast traffic.  It is highly desirable to support L3 multicast
   limited in scope to an intranet or extranet. The solution should be
   able to support a large number of such intranet or extranet specific
   multicast groups in a scalable manner.

3.2 Topology
   A PPVPN should support arbitrary, customer agent defined inter-site
   connectivity, ranging, for example, from hub-and-spoke, partial mesh
   to full mesh topology. To the extent possible, a PPVPN service should
   be independent of the geographic extent of the deployment.

   A PPVPN should support multiple VPNs per customer site.

   To the extent possible, the PPVPN services should independent of
   access network technology.

3.3 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.

   A mechanism to exchange reachability information with equipment at
   customer sites within a VPN must be provided.

   PPVPN solutions shall define means that [VPN-CRIT] prevent routers in
   a VPN from interaction with unauthorized entities and avoid
   introducing undesired routing information that could corrupt the VPN
   routing information base.



Carugi et al    Informational - Expires September 2002              11                Service requirements for Layer 3 PPVPNs     March, 2002


   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 the VPN should be invisible to the
   Internet.

   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].

3.4 Security
   A range of security features should be supported by the suite of
   PPVPN solutions [VPN SEC]. Each PPVPN solution should state which
   security features it supports and how such features can be configured
   on a per customer basis.

3.4.1  User data security
   PPVPN solutions that support user data security should use standard
   methods (e.g., IPsec) to achieve confidentiality, integrity,
   authentication and replay attack prevention.

3.4.2  Access control
   A PPVPN solution may also have the ability to activate the
   appropriate filtering capabilities upon request of a customer [VPN-
   NEEDS]. A filter provides a mechanism so that access control can be
   invoked at the point(s) of communication between different
   organizations involved in an extranet. Access control can be
   implemented by a firewall, access control lists on routers or similar
   mechanisms to apply policy-based access control to transit traffic.

3.4.3  Site authentication and authorization

   A L3 VPN solution requires authentication and authorization of the
   following:
    - temporary and permanent access for users connecting to sites
   (authentication and authorization BY the site)
    - the site itself (authentication and authorization FOR the site)

3.5 Addressing
   An L3 VPN service shall support overlapping customer addresses, for
   example non-unique private IP addresses [RFC1918].

   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 should be easily extendable to support both IPv4 and
   IPv6.

Carugi et al    Informational - Expires September 2002              12                Service requirements for Layer 3 PPVPNs     March, 2002



   A VPN service should be capable of translating customer private IP
   addresses for communicating with IP systems having public addresses.

   A VPN service may be capable of supporting non-IP customer addresses
   (e.g., IPX, Appletalk). If a VPN service supports such addresses,
   then it should be capable of translating customer private addresses
   for the purpose of communicating with systems having public
   addresses.

   FR and ATM link layer identifiers (i.e., DLCI and VPI/VCI) shall be
   unique only on a physical interface basis.

   Normally, Ethernet MAC addresses on access connections are globally
   unique.

3.6 Quality of Service
   To the extent possible, L3 VPN QoS should be independent of the
   access network technology.

3.6.1  QoS Standards
   According to the PPVPN charter, a non-goal is the development of new
   protocols or extension of existing ones. Therefore, with regards to
   QoS support, a PPPVN shall be able to support QoS in one or more of
   the following already standardized modes:
     - Best Effort  (support mandatory for all PPVPN types)
     - Aggregate CE Interface Level QoS (i.e., _hose_ level)
     - Site-to-site, or _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.

   PPVPN CE 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]

   PPVPN CE and PE should be capable of supporting differentiated
   service (diffserv). In diffserv Per Hop Behavior PHB - a description
   of the externally observable forwarding behavior of a DS node applied
   to a particular DS behavior aggregate [RFC 2475].  Diffserv-capable
   PPVPN CE and PE shall support the following per hop behavior (PHB)
   types:


Carugi et al    Informational - Expires September 2002              13                Service requirements for Layer 3 PPVPNs     March, 2002


     - Expedited Forwarding (EF) - the departure rate of an aggregate
   class of traffic from a router that must equal or exceed a configured
   rate [RFC 2598 bis].
     - Assured Forwarding (AF) - is a means for a provider 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 is in each DS node allocated a certain amount of
   forwarding resources (e.g., buffer space and bandwidth) [RFC 2597].

   A customer, 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 TCP traffic, L3 PPVPN devices should support Random Early
   Detection (RED) to provide graceful degradation in the event of
   network congestion.

   The need to provide QoS will occur primarily in the access network,
   since that will often be the bottleneck. This is likely to occur
   since the backbone effectively statistically multiplexes many users,
   is traffic engineered, and in some cases also includes capacity for
   restoration and growth. There are two directions of QoS management
   that must be considered in any PPVPN service regarding QoS:
     - From the CE across the access network to the PE
     - From the PE across the access network to CE

   PPVPN CE and PE devices should be capable of supporting QoS across a
   subset of the access networks defined in section 4.11, such as:
     - ATM Virtual Connections (VCs)
     - Frame Relay Data Link Connection Identifiers (DLCIs)
     - 802.1d Prioritized Ethernet
     - MPLS-based access
     - Multilink Multiclass PPP
     - QoS-enabled wireless (e.g., LMDS, MMDS)
     - Cable modem [DOCSIS 1.1]
     - QoS-enabled Digital Subscriber Line (DSL)

3.6.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 an edge-to-edge QoS service.

   A managed access VPN service provides QoS on the access connection
   between the CE and the PE. As an example for a L3 PPVPN service,
   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 implementation of DiffServ in the SP IP 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

Carugi et al    Informational - Expires September 2002              14                Service requirements for Layer 3 PPVPNs     March, 2002


   diffserv marking. An SP may provide several packet classification
   profiles that customers may select, or may offer a service that
   offers 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 provider edge to
   provider edge. The provider edge 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.

3.7 Service Level Specification and Agreements
   A Service Level Specification (SLS) may be defined per access network
   connection, per VPN, per VPN site, and/or per VPN route. The service
   provider may define objectives and the measurement interval for at
   least the SLS using the following Service Level Objective (SLO)
   parameters:

     O QoS and traffic parameters for the Intserv flow or Diffserv class
     O Availability for the site, VPN, or access connection
     O Duration of outage intervals per site, route or VPN
     O Service activation interval (e.g., time to turn up a new site)
     O Trouble report response time interval
     O Time to repair interval
     O Total traffic offered to the site, route or VPN
     O Measure of non-conforming traffic for the site, route or VPN

   The above list contains items from [Y.1241], as well as other items
   typically part of SLAs for currently deployed VPN services [FRF.13].
   See RFC 3198 for generic definitions of SLS, SLA, and SLO.

   The provider network management system shall measure, and report as
   necessary, whether measured performance meets or fails to meet the
   above SLS objectives.

   The service provider and the customer may negotiate a contractual
   arrangement that includes a Service Level Agreement (SLA) regarding
   compensation if the provider does not meet an SLS performance
   objective. Details of such compensation are outside the scope of this
   document.

   SLS measurements for quality based on the DiffServ scheme should be
   based upon the following classification [Y.1311.1]:

     A Point-to-Point SLS, 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-

Carugi et al    Informational - Expires September 2002              15                Service requirements for Layer 3 PPVPNs     March, 2002


     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, 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).

     A Cloud-to-Point SLS, is the case where flows originating from
     multiple sources may congest the interface from the network toward
     a specific site, which this SLS does not cover.

   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.

3.8 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 VPNs 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 6.

3.9 Interoperability
   Each technical solution should support the Internet standards (in
   terms of compatibility and modularity).

   Multi-vendor interoperability at network element, network and service
   levels among different implementations of the same technical solution
   should be guaranteed (that will likely rely on the completeness of
   the corresponding standard). This is a central requirement for SPs
   and customers.

Carugi et al    Informational - Expires September 2002              16                Service requirements for Layer 3 PPVPNs     March, 2002



   The technical solution must be multi-vendor interoperable not only
   within the SP network infrastructure, but also with the customer's
   network equipment and services making usage of the PPVPN service.

3.10 Interworking
   Service interworking among different solutions providing PPVPN
   services is highly desirable. It 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.

4 Customer Requirements
   The general requirements of section 3 apply to all customers. This
   section captures additional requirements that are specific to a
   customer perspective.

4.1 VPN Membership (Intranet/Extranet)
   When an extranet is formed, a customer agent from each of the
   organizations must approve addition of a site to an extranet VPN. The
   intent of this requirement is to ensure that both organizations
   approve extranet communication before the PPVPN allows exchange of
   traffic and routing information.

4.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.

4.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 from IANA
     o globally unique addresses statically assigned by the PPVPN
     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)



Carugi et al    Informational - Expires September 2002              17                Service requirements for Layer 3 PPVPNs     March, 2002


   In the case of combined L3 PPVPN service with non-unique or private
   addresses and Internet access, mechanisms that permit the exchange of
   traffic between the customer's private address space and the global
   unique Internet address space must be supported, for example, NAT.

4.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, such as RIP, OSPF,
   IS-IS, or BGP [PPVPN-FR].

4.5 Quality of Service and Traffic Parameters
   QoS is expected to be an important aspect of a PPVPN 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.

4.5.1  Application Level QoS Objectives
   A customer is concerned primarily that the PPVPN service provide his
   or her application has the QoS and level of traffic such that the
   application performs acceptably. Pseudo-wires (e.g., SONET emulation)
   voice and interactive video, and multimedia applications are expected
   to require the most stringent QoS. These real-time applications are
   sensitive to delay, delay variation, loss, availability and/or
   reliability. Another set of applications requires near real time
   performance. Examples are multimedia, interactive video, high-
   performance web browsing and file transfer intensive applications.
   Finally, best effort applications are not sensitive to degradation.
   That is, they 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 Differentiated service
   (Diffserv) class-based QoS.

   The fundamental customer application requirement is that a PPVPN
   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.

4.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 [Y.1311.1]. Although RFC 2475 states that interior or


Carugi et al    Informational - Expires September 2002              18                Service requirements for Layer 3 PPVPNs     March, 2002


   boundary nodes within a provider's Diffserv domain may 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 carriers' carrier service where one SP is the
     customer of another PPVPN 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 carriers' 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.

4.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
   must have access to the measures from the SP(s) that support the SLA.

4.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.

   All aspects of management information about CE devices and customer
   attributes of a PPVPN manageable by an SP should be capable of being
   configured and maintained by an authenticated, authorized customer
   agent.

   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 as service is a "Dynamic Bandwidth management"
   capability, that enables real-time response to customer requests for
   changes of allocated bandwidth allocated to their VPN(s)[Y.1311.1].

   A customer who may not be able to afford the resources to manage
   their own sites should be able to outsource the management of his or
   her VPN to the service provider(s) supporting the network.

4.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].

4.9 Security
   The suite of PPVPN solutions should support a range of security
   related features.  Higher levels of security services, like edge-to-

Carugi et al    Informational - Expires September 2002              19                Service requirements for Layer 3 PPVPNs     March, 2002


   edge encryption, authentication, or replay attack should be
   supported.

   Security in a PPVPN 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 4.11.2.

   PPVPN 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.

   A security solution deployed by a customer must not hide information
   necessary for the SP to support QoS features. For example,
   applications must send RSVP messages in support of Intserv either in
   the clear or encrypted using a key negotiated with the SP. Another
   case is where applications using an IPsec tunnel must copy the DSCP
   from the encrypted IP header to the header of the tunnel's IP header.

   Security services shall apply to:
    o either, all VPN traffic exchanged between different sites ;
    o or, a subset of the VPN traffic between sites as identified by a
    combination of the destination IP address, the Security Profile
    Index (SPI) and the IPsec AH or ESP identifier.

4.10 Migration Impact
   Often, customers are migrating from an already deployed private
   network toward one or more Provider Provisioned 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 PPVPN service should still
   have L3 reachability to the sites that migrate to the PPVPN service.

4.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 PPVPN.

4.11.1 Physical/Link Layer Technology
   PPVPNs should 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.



Carugi et al    Informational - Expires September 2002              20                Service requirements for Layer 3 PPVPNs     March, 2002


4.11.2 Temporary Access
   The VPN service offering should allow both permanent and temporary
   access to one or more PPVPNs 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 servers.

   A significant number of VPN users are not 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 VPN
   communication.

   A user should be able to access a PPVPN via a network having generic
   Internet access.

   Mobile users may move within a PPVPN site. Mobile users may also
   temporarily connect to another PPVPN site within the same VPN.
   Authentication should be provided for both of these cases.

4.11.3 Sharing of the Access Network
   In a PE-based PPVPN, if the site shares the access network with other
   customer traffic, then data security in the access network is the
   responsibility of the PPVPN customer.

4.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. PPVPN solutions should
   support at least the types of physical or link-layer connectivity
   arrangements shown in Figure 4.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.

Carugi et al    Informational - Expires September 2002              21                Service requirements for Layer 3 PPVPNs     March, 2002


                  +----------------                    +---------------
                  |                                    |
               +------+                            +------+
     +---------|  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 4.1 Representative types of access arrangements.

Carugi et al    Informational - Expires September 2002              22                Service requirements for Layer 3 PPVPNs     March, 2002



   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 CE's
   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
   PPVPN 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).

4.12 Service Access
   Customers may also require access to other services, as described in
   this section.

4.12.1 Internet Access
   Customers should be able to have L3 PPVPN 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 PPVPN 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 PPVPN 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 4.3, network address translation (NAT) or
   similar mechanism must be provided either by the customer or the SP
   in order to be able to interchange traffic between devices assigned
   non-unique or private IP addresses and devices that have unique IP
   addresses.

4.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
   PPVPN service.

4.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.


Carugi et al    Informational - Expires September 2002              23                Service requirements for Layer 3 PPVPNs     March, 2002


4.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
   PPVPN solutions in such a way that does not overly complicate
   provisioning, management, scalability, or performance.

5 Service Provider Network Requirements
   This section describes requirements from a service provider
   perspective.

5.1 Scalability
   This section contains projections regarding PPVPN sizing projections
   and scalability requirements and metrics specific to particular
   solutions.

5.1.1  Service Provider Capacity Sizing Projections
   This section captures projections for scaling requirements over the
   next several years in terms of number of VPNs, number of interfaces
   per VPN, number of routes per VPN, and the rate of VPN configuration
   changes. These numbers provide a baseline against which the
   scalability of specific approaches can be assessed. These values were
   derived from ITU-T [Y.1311.1] and inputs from service providers.

   A PPVPN solution should be scalable to support a very large number of
   VPNs per Service Provider network. The estimate is that a large
   service provider will require support for on the order of 10,000 VPNs
   within four years.

   A PPVPN solution should be scalable to support of a wide range of
   number of site interfaces per VPN, depending on the size and/or
   structure of the customer organization. The number of site interfaces
   should range from a few site interfaces to over 50,000 site
   interfaces per VPN.

   A PPVPN solution should be scalable to support of a wide range of
   number of routes per VPN. The number of routes per VPN may range from
   just a few to the number of routes exchanged between ISPs using BGP
   (in 2001, on the order of 100,000). Typically, the number of routes
   per VPN is O(2N), where N is the number of site interfaces.

   A PPVPN solution should support high values of the frequency of
   configuration setup and change, e.g. for real-time provisioning of an
   on-demand videoconferencing VPN. As a guideline, an estimate on the
   VPN frequency of change (e.g., addition/removal of sites per VPN per


Carugi et al    Informational - Expires September 2002              24                Service requirements for Layer 3 PPVPNs     March, 2002


   time unit) could be as large as 1 million per year across all service
   providers within the next four years.

   Approaches should articulate scaling and performance limits for more
   complex deployment scenarios, such as inter-AS(S) VPNs and carriers'
   carrier. Approaches should also describe other dimensions of
   interest, such as capacity requirements or limits, number of
   interworking instances supported as well as any scalability
   implications on management systems.

5.1.2  Solution-Specific Metrics
   Each PPVPN solution shall document its scalability characteristics in
   quantitative terms. Two examples are provided below as an
   illustration.

   The following example applies to the number of tunnels necessary in
   various devices in the network. In a PE-based VPN, edge-to-edge
   tunnels (PE-to-PE) need to be established, while in a CE-based VPN,
   end-to-end tunnels between pairs of CE's are necessary. Therefore,
   fewer tunnels need to be maintained in a PE-based solution and
   scalability could be improved over that of CE-based VPNs e.g. ATM,
   FR, IPsec). The other tradeoff is that in a PE-based solution, the CE
   is simple at the expense of complex PE devices, while on the other
   hand, in a CE-based solution, the PE devices remain simple while the
   CE devices are more complex.

   A scalable PE-based solution should quantify the amount of state that
   a PE and P router must support. This should be stated in terms of of
   the total number of VPNs and site interfaces supported by the service
   provider. Ideally, all VPN-specific state should be contained in the
   PE router, since routing and/or configuration information depends
   only on the VPNs whose site(s) are connected to that PE. However,
   this should be balanced against the requirements of specific
   services, such as multicast, which may require per VPN state in the P
   router.

5.2 Addressing
   As described in section 3.4, SPs require 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 PPVPN solutions.

   A L3 PPVPN solution must be able to assign blocks of addresses form
   its own public IP address space to PPVPN customer sites in such a way
   that advertisement of routes to other SPs and other sites aggregates
   efficiently.

   A PPVPN solution must be able to use address assignments made by a
   customer. These customer assigned addresses may be public, or
   private.



Carugi et al    Informational - Expires September 2002              25                Service requirements for Layer 3 PPVPNs     March, 2002


   In the case where private IP addresses are used, a PPVPN 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.

5.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 networkswhen supporting a VPN that spans
   multiple SPs. Ideally, this identifier should be globally unique
   (e.g., an AS number).

   A 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.

   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.

5.4 Learning VPN Related Information
   Configuration of CE and PE devices is a significant task for a
   service provider. Solutions should strive to contain methods that
   that dynamically allows VPN information to be learned (or discovered)
   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 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 allows authentication of the source.

Carugi et al    Informational - Expires September 2002              26                Service requirements for Layer 3 PPVPNs     March, 2002



   Distribution of VPN information should be limited to those PEs
   involved in that VPN.

   The mechanism should respond to VPN membership changes in a timely
   manner. A "timely manner" is no longer than the provisioning
   timeframe, and may be as short as the timeframe required for
   "rerouting."

   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 PPVPN solution.

5.5 SLA and SLS Support
   Typically, a Service Provider offering a PPVPN service commits to
   specific Service Level Specifications (SLS) as part of a contract
   with the customer, as described in section 3.7. Such a Service Level
   Agreement (SLA) drives the following specific SP requirements for
   measuring Specific Service Level Specifications (SLS) for quality,
   availability, response time, and configuration intervals.

5.6 Quality of Service (QoS) and Traffic Engineering
   A significant aspect of a PPVPN 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 service provider to provide
   either managed QoS access service, or edge-to-edge QoS service, as
   defined in section 3.6.2.

   Each PPVPN approach must describe the traffic engineering techniques
   available for a service provider 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
   DifServ marking to marking used in a SP network should be provided
   for L3 PPVPN services.

   In the case where a customer requires DSCP transparency, as described
   in section 4.5.2, a L3 PPVPN service must deliver the same value of
   DSCP field in the IP header received from the customer to the egress
   demarcation of the destination.

5.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 be secured, for example, using MD5

Carugi et al    Informational - Expires September 2002              27                Service requirements for Layer 3 PPVPNs     March, 2002


   authentication. Additional parameters to isolate routing usage of
   resources should be supported, such as BGP route dampening and a
   maximum number of routes accepted per VFI [MPLS SEC].

   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.
   Furthermore, it is desirable that an SP should have a choice with
   regards to the IGP routing protocol.

   The additional routing burden that a Service Provider must
   carry should be articulated in each specific L3 PPVPN solution.

5.8 Isolation of Traffic and Routing
   The internal structure of a PPVPN 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 PPVPN 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 PPVPN solution should provide a means for meeting PPVPN QoS SLA
   requirements that isolates VPN traffic from the affects of traffic
   offered by non-VPN customers. Also, PPVPN 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.

   The following example illustrates this requirement for a L3 PE-based
   VPN. It assumes that a network contains three PE devices (1, 2, and
   3) that supports three VPNs (A, B and C). Assume also that each PE
   dedicates one access port to a site for each of the three VPNs.

   Each PE must maintain at most three L3 forwarding tables, one for
   each of the three VPNs. Note that if a PE does not support a
   particular VPN, it need not maintain a table for that VPN. A PE may
   also support a fourth table in a L3 VPN service for access to the
   Internet. A PE must forward a datagram received from a CE according
   to the forwarding table for that VPN, as defined in section 2.6. If
   the switching or forwarding table does not contain a relevant entry,
   the PE should execute one of the following procedures, depending upon
   its configuration:

     1) discard the datagram

Carugi et al    Informational - Expires September 2002              28                Service requirements for Layer 3 PPVPNs     March, 2002


     2) attempt to forward the datagram based upon information obtained
   from the general forwarding table for a L3 VPN service

   The PE MUST NOT forward the datagram based upon information obtained
   from any switching or forwarding table related to any other VPN.

   PE devices in a L3 VPN must isolate VPNs from one another with
   respect to the distribution of routing information. For example, in
   the network described above, assume that PE 1 is connected directly
   to CE A1, which is a member of VPN A. PE 1 may distribute routing
   information concerning CE A1 to PE's 2 and 3. PEs 2 and 3 may install
   this information in the forwarding table that supports VPN A, but not
   in any other VPN forwarding tables.

5.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 PPVPN.

5.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 PPVPN 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 it claims
     to be,
     o replay attack prevention, to prevent a "man in the middle"
     attack.

   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
   not necessarily perceived by the customer but nevertheless essential
   to maintain his or her VPN. Note that it may be necessary to extend
   the IPsec protocol to support exchange of control traffic over an
   IPsec tunnel [IPSEC-PPVPN].

   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].


Carugi et al    Informational - Expires September 2002              29                Service requirements for Layer 3 PPVPNs     March, 2002


   A VPN solution may support one or more encryption schemes, including
   DES, 3DES. Encryption, decryption, and key management should be
   included in profiles as part of the security management system.

5.9.2  Authentication Services
   A service provider must provide authentication services in support of
   temporary user access requirements, as described in section 4.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
   5.4. When network elements must cooperate, it is necessary to
   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 PPVPN 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.

5.9.3  Resource Protection
   Recall from the definitions in section 2.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,
   - 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).


Carugi et al    Informational - Expires September 2002              30                Service requirements for Layer 3 PPVPNs     March, 2002


   In order to address the above threats and risks, a SP should be able
   to deploy functions that control access to the site. This includes
   filtering functions provided by firewall, and monitoring, alerting
   and eventually logging all suspicious activities in order to detect
   potential attacks. Another way to prevent such an attack is to make
   sure that machines are not reachable via address hiding [MPLS SEC].

   The devices in the PPVPN network must provide some means of reporting
   intrusion attempts to the service provider.

5.10 Inter-AS (SP)VPNs
   The scenario for VPNs spanning multiple Autonomous Systems (AS)or
   Service Providers (SP) is a complex one that requires
   standardization.  The scenarios where multiple AS's 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 2.

   In each scenario, all applicable SP requirements, such as traffic and
   routing isolation, SLA's, management, security, provisioning, etc.
   must be preserved across adjacent AS's. The solution 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 service providers involved that spells out at least
   trust, economic, and management responsibilities.

   The overall scalability of the VPN service must allow the PPVPN
   service to be offered across potentially hundreds of SPs, with the
   overall scaling parameters per SP given in section 5.1.

5.10.1 Routing Protocols
   If the link between AS's or SP's is not trusted, routing protocols
   running between those AS's or SP's 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].

   AS's/SP's should specify the AS-path and other attributes in a
   standard routing protocol (e.g., BGP) to control the path taken by
   PPVPN traffic.

5.10.2 Management
   The general requirements for managing a single AS apply to a
   concatenation of AS's. A minimum subset of such capabilities is the
   following:
     - Diagnostic tools (e.g., ping, traceroute)
     - Secured access to one AS management system by another
     - Configuration request and status query tools
     - Fault notification and trouble tracking tools



Carugi et al    Informational - Expires September 2002              31                Service requirements for Layer 3 PPVPNs     March, 2002


5.10.3 Bandwidth and Qos Brokering
   When a VPN spans multiple AS's, there is a need 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. The essential requirement is that a
   solution must be able to determine whether a set of AS's can
   establish and guarantee uniform QoS in support of a PPVPN.

   The brokering mechanism can be a manual one, for example, where one
   provider requests from another provider a specific set of 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 SLA/QoS parameters. For instance, in
   the case of a L3 PPVPN, 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.

   In the case of an automated function, which is desirable, the
   functionality supported should dynamically request and reserve
   certain QoS parameters such as bandwidth and priority, and then to
   classify, mark and handle the packets as agreed in the negotiation.
   Observe that as traffic might traverse multiple AS's, the brokering
   method should also allow this.

   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 AS's. 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 tunnnel basis between PE routers in different AS's
   supporting a L3 PPVPN service.

5.10.4 Security Considerations
   If a tunnel traverses multiple SP networks and it passes through an
   unsecure SP, POP, NAP, or IX, then security mechanisms must be
   employed.

5.11 PPVPN 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 PPVPN service at wholesale to another
   service provider, who then resells that VPN service to his or her
   customers.

   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. This is called a hierarchical VPN
   scenario.

Carugi et al    Informational - Expires September 2002              32                Service requirements for Layer 3 PPVPNs     March, 2002



   The Carrier's carrier scenario is the name used in this document for
   this category of PPVPN wholesale. Various Carrier's Carrier scenarios
   should be supported, such as:
  -     the customer Carriers do not operate PPVPN services for their
     clients;
  -     the customer Carriers operate PPVPN services for their clients,
     but these services are not linked with the PPVPN service offered
     by the Carriers' Carrier;
  -     the customer Carriers operate PPVPN services for their clients and
     these services are linked with the PPVPN service offered by the
     Carriers' Carrier ("Hierarchical VPNs" scenario)

5.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, MPLS, IP-in-IP, etc.

   To set up tunnels between PE routers, every PE router must support
   static configuration for tunneling and may support a tunnel setup
   protocol. If employed, a tunnel establishment protocol must convey
   information regarding:
     - Relevant identifiers
     - QoS/SLA
     - Restoration
     - Multiplexing

   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.

5.13 Support for Access and Backbone Technologies
   This section describes requirements for aspects of access and
   backbone network technologies from a service provider point of view.

   Some SPs may desire that a single network infrastructure should
   suffice for all services, public IP, VPNs, traffic engineering, and
   differentiated services [L2 VPN].

5.13.1 Dedicated Access Networks
   Ideally, the PPVPN 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.


Carugi et al    Informational - Expires September 2002              33                Service requirements for Layer 3 PPVPNs     March, 2002


5.13.2 On-Demand Access Networks
   Service providers should be able to support temporary user access, as
   described in section 4.11.2 using dedicated or dial-in access network
   technology.

   PPVPN 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 PPVPN 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 is
   required: PAP, CHAP and EAP, since they are currently used in a wide
   range of equipment and services.

5.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.

5.14 Protection, Restoration
   When primary and secondary access connections are available, a PPVPN
   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, reversion to the
   primary link should be dynamic, if configured to do so [VPN-NEEDS].

   As mentioned in Section 4.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.

Carugi et al    Informational - Expires September 2002              34                Service requirements for Layer 3 PPVPNs     March, 2002



   The Service provider should be able to deploy protection and
   restoration mechanisms within the service provider's 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.

5.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 PPVPN services across two or more interconnected SP
     networks
     - To achieve interworking or interconnection between customer sites
     using different PPVPN 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].

5.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 PPVPN
   approach.

   If PPVPN 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.

6 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, the service provider 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

Carugi et al    Informational - Expires September 2002              35                Service requirements for Layer 3 PPVPNs     March, 2002


   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 service provider
   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.

6.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
   network management system 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). 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 PPVPN must be provided for diagnostic purposes.

6.2 Configuration Management
   Overall, The NMS must support configuration necessary to realize
   desired L3 reachability of a PPVPN. Toward this end, an NMS must
   provide configuration management to provision at least the following
   PPVPN 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

Carugi et al    Informational - Expires September 2002              36                Service requirements for Layer 3 PPVPNs     March, 2002


   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, preshared keys if any, and
   traffic filters. A BGP/MPLS service template would contain fields
   such as the sites that need to form a VPN. 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,
   conflicting service requirements.

6.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.



Carugi et al    Informational - Expires September 2002              37                Service requirements for Layer 3 PPVPNs     March, 2002


   o The NMS should use identifiers for SPs, PPVPNs, PEs, CEs,
   hierarchical tunnels and access connections as described in section
   5.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 PPVPN must be coordinated with the
   configuration of the underlying infrastructure, including Layer 1 and
   2 networks interconnecting components of a PPVPN.

6.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.

6.2.3  Provisioning Routing
   A means for a service provider to provision parameters for the IGP
   for a PPVPN must be provided. This includes link level metrics,
   capacity, QoS capability, and restoration parameters.

6.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.

6.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 a intrusion detection service, the filtering and
   detection rules must be provisioned on a VPN basis.


Carugi et al    Informational - Expires September 2002              38                Service requirements for Layer 3 PPVPNs     March, 2002


6.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
   dates, times, amounts and interval required to perform requested
   bandwidth allocation change(s) must be traceable for accounting
   purposes.

   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).
   Example SLA parameters are response time and probability of being
   able to service such a request

6.2.7  Provisioning Value-Added Service Access
   A PPVPN 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 customers from one
   or many servers.

   A firewall function may be required to restrict access to the PPVPN
   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.

   Managed firewalls must be supported on a per-VPN basis, although
   multiple VPNs may be supported by the same physical device (e.g., in
   network or PE-based solution).  Managed firewalls should be provided

Carugi et al    Informational - Expires September 2002              39                Service requirements for Layer 3 PPVPNs     March, 2002


   at the major access point(s) for the PPVPN. Managed firewall services
   may be embedded in the CE or PE devices, 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 a third party.

   The management system should support collection of information
   necessary for optimal allocation of IP services in response to
   customer orders.

   Network-based firewall services must be carrier grade. For redundancy
   and failure recovery, a means for firewall fail-over should be
   provided. Network-based firewall services that may be provided
   include dropping specified protocol types, intrusion detection,
   traffic-rate limiting against malicious attacks, etc.

   Network-based firewalls must be supported on a per-VPN basis,
   although multiple VPNs may be supported by the same physical device.
   Network-based firewalls should be provided at the major access
   point(s) for the PPVPN. Network-based firewall services may be
   embedded in the PE equipment, or implemented in standalone equipment.

   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.

6.2.8  Provisioning Hybrid VPN Services
   Configuration of interworking or interconnection between PPVPN
   solutions should be also supported. Ensuring that security and end-
   to-end QoS issues are provided consistently should be addressed.

6.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 PPVPN 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

Carugi et al    Informational - Expires September 2002              40                Service requirements for Layer 3 PPVPNs     March, 2002


   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.

6.4 Performance Management
   Performance management includes 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 PPVPN , such as bandwidth utilization, response time,
   availability, QoS statistics, and trends based on collected data.

6.4.1  Performance Monitoring
   The NMS must monitor device behavior to evaluate performance metrics
   associated with a service level agreement. 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.

6.4.2  SLA and QoS management features
   The NMS should support SLAs between the SP and the various 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 network(s).

   Devices supporting PPVPN SLAs should have real-time performance
   measurements that have indicators and threshold crossing alerts. Such
   thresholds should be configurable.

6.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 PPVPN network(s), as well as the security of
   customer data and control as described in section 5.9.


Carugi et al    Informational - Expires September 2002              41                Service requirements for Layer 3 PPVPNs     March, 2002


6.5.1  Management Access Control
   Management access control determines the privileges that a user has
   for particular applications and parts of the network. Without such
   control, only the security of the data and control traffic is
   protected, leaving the devices providing the PPVPN network
   unprotected. 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.

6.5.2  Authentication
   Authentication is the process of verifying that the sender is
   actually is who he or she says they are. 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.

   Support for strong authentication schemes shall be supported to
   ensure the security of both VPN access point-to-VPN access point  (PE
   to PE) and client-to-VPN Access point (CE-to-PE) communications. This
   is particularly important to prevent VPN access point 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 convinces a PE or CE of that, then the device will send
   VPN traffic to the attacker (who could forward it on to your true
   access point after compromising confidentially 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.
   However, strongly-authenticated VPN APs are not subject to such
   attacks, because the man-in-the-middle cannot authenticate as the
   real AP, due to the strong authentication algorithms.

6.6 Network Management Techniques
   Each PPVPN solution approach must specify the management or policy
   information bases (MIBs or PIBS) for network elements involved in
   PPVPN 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.

   The IP VPN Policy Information model should reuse the policy
   information models being developed in parallel for specific IP
   network capabilities [IM-REQ]. This includes the QoS Policy

Carugi et al    Informational - Expires September 2002              42                Service requirements for Layer 3 PPVPNs     March, 2002


   Information Model_[QPIM] and the IPSEC Configuration Policy Model_
   [IPSECIM]. The information model should provide the OSS with adequate
   "hooks" to correlate service level specifications 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 information models are given in reference
   [IM-PPVPN]. In particular, an information model must allow a service
   provider to change network dimensions with minimal influence on
   provisioning issues. The adopted model should be applicable to both
   small/medium size networks and large-scale PPVPN solutions.

   Some service providers may require systems that visually, audibly, or
   logically present FCAPS information to internal operators and/or
   customers.

7 Security Considerations
   Security considerations occur at several levels and dimensions within
   Provider Provisioned 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 as detailed in section 3.4 from that of isolating (or
   separating) the exchange of forwarded packets and exchange of routing
   information between specific sets of sites, as defined in sections
   2.3 and 3.3. Further detail on security requirements are given from
   the customer and service provider perspectives in sections 3.4 and
   4.9, respectively. In an analogous manner, further detail on traffic
   and routing isolation requirements are given from the customer and
   service provider perspectives in sections 3.3 and 4.8, respectively.

   Furthermore, requirements regarding management of security from a
   service provider perspective are described in section 6.5.

8 Acknowledgements
   The authors of this document would like to acknowledge the
   contributions from the ITU-T people who launched the work on VPN
   requirements inside SG13, the authors of the original IP VPN
   requirements and framework document [RFC 2764], Tom Worster, Ron
   Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, Nail Akar, Derek
   Atkins, Bryan Gleeson, Greg Burns, and Frederic LeGarrec. The authors
   are also grateful to the helpful suggestions and direction provided
   by the technical advisors, Scott Bradner, Bert Wijnen and Rob Coltun.
   We would also like 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 et al    Informational - Expires September 2002              43                Service requirements for Layer 3 PPVPNs     March, 2002



9 References
   [RFC1777]   Yeong, W. et al., "Lightweight Directory Access
               Protocol," RFC 1777, March 1995.
   [RFC2026]   Bradner, S., "The Internet Standards Process --  Revision
               3", BCP 9, RFC 2026, October 1996.
   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997
   [RFC2251]   Wahl, M. et al., "Lightweight Directory Access Protocol
               (v3)," RFC 2251, December 1997.
   [RFC2661]   Townsley, W. et al., "Layer Two Tunneling Protocol
               "L2TP"," RFC 2661, August 1999.
   [RFC2547]   E. Rosen, Y. Rekhter, _BGP/MPLS VPNs,_ RFC 2547,March
               1999.
   [2547bis]   Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work in
               progress.
   [RFC2764]   Gleeson, B., et al., "A Framework for IP based Virtual
               Private Networks", RFC 2764, February 2000
   [2917bis]   Muthukrishnan, K., et al., _ A Core MPLS IP VPN
               Architecture_, work in progress
   [PPVPN-FR]  Callon, R., Suzuki, M., et al. "A 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
   [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
   [VPN-VR]    Ould-Brahim, H., Gleeson,  B., et al.  _Network based IP
               VPN  Architecture   using  Virtual  Routers_,   work  in
               progress
   [Y.1241]    "IP Transfer Capability for the support of IP based
               Services", Y.1241 ITU-T Draft Recommendation, March 2000
   [Y.1311.1]  Carugi, M. (editor), "Network Based IP VPN over MPLS
               architecture",Y.1311.1 ITU-T Recommendation, May 2001
               (http://ppvpn.francetelecom.com/ituRelated.html)
   [Y.1311]    Knightson, K. (editor), " Network based IP VPN Service -
               Generic Framework and Service Requirements ", Y.1311 ITU-
               T Draft Recommendation, May 2001
               (http://ppvpn.francetelecom.com/ituRelated.html)

   [L2 VPN]    E. Rosen et al, "An Architecture for L2VPNs," work in
               progress.
   [L2 MPLS]   L. Martini et al, _Transport of Layer 2 Frames Over
               MPLS,_ work in progress.
   [RFC 2205]  R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S.
               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
               Functional Specification," September 1997.



Carugi et al    Informational - Expires September 2002              44                Service requirements for Layer 3 PPVPNs     March, 2002


   [RFC 2211]  J. Wroclawski, Specification of the Controlled-Load
               Network Element Service, RFC 2211, IETF, September 1997.
   [RFC 2212]  S. Shenker, C. Partridge, R Guerin, Specification of
               Guaranteed Quality of Service, RFC 2212, IETF, September
               1997.
   [RFC 2475]  S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W.
               Weiss,   "An Architecture for Differentiated Services",
               RFC  2475, Dec. 1998.
   [RFC 2597] "Assured Forwarding PHB Group", F. Baker, J. Heinanen, W.
               Weiss, J. Wroclawski, RFC 2597,
   [RFC 2598] "An Expedited Forwarding PHB", V.Jacobson, K.Nichols,
               K.Poduri, RFC 2598
   [RFC 2598 bis] B. Davie et al, "An Expedited Forwarding PHB", work in
               progress.
   [RFC 2983]   Black, D., _Differentiated Services and Tunnels_,
               RFC2983, October 2000
   [PPVPN-FR]  R. Callon, M. Suzuki, B. Gleeson, A. Malis, K.
               Muthukrishnan, E. Rosen, C. Sargor, J. Yu, "A Framework
               for Provider Provisioned Virtual Private Networks," work
               in progress.
   [RFC 1918]  Rekhter, Y. et al., "Address Allocation for Private
               Internets," RFC 1918, February 1996.
   [MPLS SEC]  M. Behringer, "Analysis of the Security of the MPLS
               Architecture," work in progress
   [VPN TUNNEL] T. Worster et al, "A PPVPN Layer Separation: VPN Tunnels
               and Core Connectivity," work in progress
   [IM-REQ]    M.Iyer et al, "Requirements for an IP VPN Policy
               Information Model," work in progress
   [IPSECIM]   J. Jason, _"IPsec Configuration Policy Model," work in
               progress.
   [QPIM]      Snir, Ramberg, Strassner, Cohen and Moore,_"Policy QoS
               Information Model" work in progress.
   [IM-PPVPN]  P. Lago et al, "An Information Model for Provider
               Provisioned Virtual Private Networks," work in progress.
   [VPN IW]    H. Kurakami et al, "Provider-Provisioned VPNs
               Interworking," work in progress.
   [L2 VPN?]   K. Kompella, R. Bonica, "Whither Layer 2 VPNs?," work in
               progress.
   [VPN SEC]   J. De Clercq et al, "Considerations about possible
               security extensions to BGP/MPLS VPN," work in progress.
   [IPSEC-PPVPN] B. Gleeson, "Uses of IPsec with Provider Provisioned
               VPNs," work in progress.
   [RFC 2685]  Fox B., et al, "Virtual Private Networks Identifier", RFC
               2685, September 1999.
   [FRF.13]    Frame Relay Forum, "Service Level Definitions
               Implementation Agreement," August, 1998.
   [RFC 3031]  E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
               Switching Architecture," January 2001.
   [DOCSIS 1.1] Data Over Cable Service Interface Specification
               (DOCSIS), Cable Labs,
               http://www.cablemodem.com/specifications.html


Carugi et al    Informational - Expires September 2002              45                Service requirements for Layer 3 PPVPNs     March, 2002


   [VPN DISC]  M. Squire et al, "VPN Discovery Discussions and Options,"
               work in progress.
   [VPLS REQ]  W. Augustyn et al, "Requirements for Virtual Private LAN
               Services (VPLS)," work in progress.
   [RFC 3198]  A. Westerinen et al, "Terminology for Policy-Based
               Management," November, 2001.
   [RFC 2975]  B. Aboba et al, "Introduction to Accounting Management,"
               October 2000.

10   Authors' address

   Marco Carugi (Co-editor)
   France Telecom Research and Development
   Technopole Anticipa _ 2, av. Pierre Marzin
   22307 Lannion cedex, France Phone : + 33 2 96 05 36 17
   Fax    : + 33 2 96 05 18 52
   marco.carugi@francetelecom.com

   Dave McDysan (Co-editor)
   WorldCom
   22001 Loudoun County Parkway
   Ashburn, VA 20147, USA
   dave.mcdysan@wcom.com

   Luyuan Fang
   AT&T
   200 Laurel Ave - Room C2-3B35
   Middletown, NJ 07748 USA
   Luyuanfang@att.com

   Fredrik Johansson
   Telia Research
   5E-123 86 Farsta, Sweden
   fredrik.xz.johansson@trab.se
   +4670 6040 987

   Ananth Nagarajan
   Sprint
   9300 Metcalf Ave,
   Overland Park, KS 66212, USA
   ananth.nagarajan@mail.sprint.com

   Junichi Sumimoto
   NTT Information Sharing Platform Labs.
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: sumimoto.junichi@lab.ntt.co.jp

   Rick Wilder
   Masergy
   rwilder@masergy.com


Carugi et al    Informational - Expires September 2002              46                Service requirements for Layer 3 PPVPNs     March, 2002



   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 et al    Informational - Expires September 2002              47


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/