tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4031

Informational
Pages: 50
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: L3VPN

Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)

Part 1 of 3, p. 1 to 15
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                     M. Carugi, Ed.
Request for Comments: 4031                               Nortel Networks
Category: Informational                                  D. McDysan, Ed.
                                                                     MCI
                                                              April 2005


                    Service Requirements for Layer 3
         Provider Provisioned Virtual Private Networks (PPVPNs)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document provides requirements for Layer 3 Virtual Private
   Networks (L3VPNs).  It identifies requirements applicable to a number
   of individual approaches that a Service Provider may use to provision
   a Virtual Private Network (VPN) service.  This document expresses a
   service provider perspective, based upon past experience with 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 perspective as well as that of a service provider.

Table of Contents

   1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  3
        1.1.  Scope of This Document. . . . . . . . . . . . . . . . .  4
        1.2.  Outline . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.   Contributing Authors. . . . . . . . . . . . . . . . . . . . .  5
   3.   Definitions . . . . . . . . . . . . . . . . . . . . . . . . .  5
        3.1.  Virtual Private Network . . . . . . . . . . . . . . . .  6
        3.2.  Users, Sites, Customers, and Agents . . . . . . . . . .  6
        3.3.  Intranets, Extranets, and VPNs. . . . . . . . . . . . .  6
        3.4.  Networks of Customer and Provider Devices . . . . . . .  7
        3.5.  Access Networks, Tunnels, and Hierarchical Tunnels. . .  7
        3.6.  Use of Tunnels and Roles of CE and PE in L3VPNs . . . .  8
              3.6.1.  PE-Based L3VPNs and Virtual Forwarding
                      Instances . . . . . . . . . . . . . . . . . . .  8
              3.6.2.  CE-Based L3VPN Tunnel Endpoints and Functions . 10

Top      ToC       Page 2 
        3.7.  Customer and Provider Network Management. . . . . . . . 10
   4.   Service Requirements Common to Customers and Service
        Providers . . . . . . . . . . . . . . . . . . . . . . . . . . 11
        4.1.  Isolated Exchange of Data and Routing Information . . . 11
        4.2.  Addressing. . . . . . . . . . . . . . . . . . . . . . . 12
        4.3.  Quality of Service. . . . . . . . . . . . . . . . . . . 12
              4.3.1.  QoS Standards . . . . . . . . . . . . . . . . . 12
              4.3.2.  Service Models. . . . . . . . . . . . . . . . . 13
        4.4.  Service Level Specification and Agreements. . . . . . . 14
        4.5.  Management. . . . . . . . . . . . . . . . . . . . . . . 14
        4.6.  Interworking. . . . . . . . . . . . . . . . . . . . . . 15
   5.   Customer Requirements . . . . . . . . . . . . . . . . . . . . 15
        5.1.  VPN Membership (Intranet/Extranet). . . . . . . . . . . 15
        5.2.  Service Provider Independence . . . . . . . . . . . . . 16
        5.3.  Addressing. . . . . . . . . . . . . . . . . . . . . . . 16
        5.4.  Routing Protocol Support. . . . . . . . . . . . . . . . 16
        5.5.  Quality of Service and Traffic Parameters . . . . . . . 16
              5.5.1.  Application Level QoS Objectives. . . . . . . . 17
              5.5.2.  DSCP Transparency . . . . . . . . . . . . . . . 17
        5.6.  Service Level Specification/Agreement . . . . . . . . . 18
        5.7.  Customer Management of a VPN. . . . . . . . . . . . . . 18
        5.8.  Isolation . . . . . . . . . . . . . . . . . . . . . . . 18
        5.9.  Security. . . . . . . . . . . . . . . . . . . . . . . . 19
        5.10. Migration Impact. . . . . . . . . . . . . . . . . . . . 19
        5.11. Network Access. . . . . . . . . . . . . . . . . . . . . 19
              5.11.1. Physical/Link Layer Technology. . . . . . . . . 20
              5.11.2. Temporary Access. . . . . . . . . . . . . . . . 20
              5.11.3. Sharing of the Access Network . . . . . . . . . 20
              5.11.4. Access Connectivity . . . . . . . . . . . . . . 20
        5.12. Service Access. . . . . . . . . . . . . . . . . . . . . 23
              5.12.1. Internet Access . . . . . . . . . . . . . . . . 23
              5.12.2. Hosting, Application Service Provider . . . . . 24
              5.12.3. Other Services. . . . . . . . . . . . . . . . . 24
        5.13. Hybrid VPN Service Scenarios. . . . . . . . . . . . . . 24
   6.   Service Provider Network Requirements . . . . . . . . . . . . 24
        6.1.  Scalability . . . . . . . . . . . . . . . . . . . . . . 24
        6.2.  Addressing. . . . . . . . . . . . . . . . . . . . . . . 25
        6.3.  Identifiers . . . . . . . . . . . . . . . . . . . . . . 25
        6.4.  Discovering VPN Related Information . . . . . . . . . . 26
        6.5.  SLA and SLS Support . . . . . . . . . . . . . . . . . . 26
        6.6.  Quality of Service (QoS) and Traffic Engineering. . . . 27
        6.7.  Routing . . . . . . . . . . . . . . . . . . . . . . . . 27
        6.8.  Isolation of Traffic and Routing. . . . . . . . . . . . 28
        6.9.  Security. . . . . . . . . . . . . . . . . . . . . . . . 28
              6.9.1.  Support for Securing Customer Flows . . . . . . 28
              6.9.2.  Authentication Services . . . . . . . . . . . . 29
              6.9.3.  Resource Protection . . . . . . . . . . . . . . 30
        6.10. Inter-AS (SP)VPNs . . . . . . . . . . . . . . . . . . . 30

Top      ToC       Page 3 
              6.10.1. Routing Protocols . . . . . . . . . . . . . . . 31
              6.10.2. Management. . . . . . . . . . . . . . . . . . . 31
              6.10.3. Bandwidth and QoS Brokering . . . . . . . . . . 31
              6.10.4. Security Considerations . . . . . . . . . . . . 32
        6.11. L3VPN Wholesale . . . . . . . . . . . . . . . . . . . . 32
        6.12. Tunneling Requirements. . . . . . . . . . . . . . . . . 33
        6.13. Support for Access and Backbone Technologies. . . . . . 33
              6.13.1. Dedicated Access Networks . . . . . . . . . . . 34
              6.13.2. On-Demand Access Networks . . . . . . . . . . . 34
              6.13.3. Backbone Networks . . . . . . . . . . . . . . . 35
        6.14. Protection, Restoration . . . . . . . . . . . . . . . . 35
        6.15. Interoperability. . . . . . . . . . . . . . . . . . . . 35
        6.16. Migration Support . . . . . . . . . . . . . . . . . . . 36
   7.   Service Provider Management Requirements. . . . . . . . . . . 36
        7.1.  Fault Management. . . . . . . . . . . . . . . . . . . . 37
        7.2.  Configuration Management. . . . . . . . . . . . . . . . 37
              7.2.1.  Configuration Management for PE-Based VPNs. . . 38
              7.2.2.  Configuration Management for CE-Based VPNs. . . 39
              7.2.3.  Provisioning Routing. . . . . . . . . . . . . . 39
              7.2.4.  Provisioning Network Access . . . . . . . . . . 39
              7.2.5.  Provisioning Security Services. . . . . . . . . 40
              7.2.6.  Provisioning VPN Resource Parameters. . . . . . 40
              7.2.7.  Provisioning Value-Added Service Access . . . . 40
              7.2.8.  Provisioning Hybrid VPN Services. . . . . . . . 41
        7.3.  Accounting. . . . . . . . . . . . . . . . . . . . . . . 41
        7.4.  Performance Management. . . . . . . . . . . . . . . . . 42
              7.4.1.  Performance Monitoring. . . . . . . . . . . . . 42
              7.4.2.  SLA and QoS Management Features . . . . . . . . 42
        7.5.  Security Management . . . . . . . . . . . . . . . . . . 43
              7.5.1.  Resource Access Control . . . . . . . . . . . . 43
              7.5.2.  Authentication. . . . . . . . . . . . . . . . . 43
        7.6.  Network Management Techniques . . . . . . . . . . . . . 44
   8.   Security Considerations . . . . . . . . . . . . . . . . . . . 44
   9.   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
   10.  References. . . . . . . . . . . . . . . . . . . . . . . . . . 45
        10.1. Normative References. . . . . . . . . . . . . . . . . . 45
        10.2. Informative References. . . . . . . . . . . . . . . . . 46
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 50

1.  Introduction

   This section describes the scope and outline of the 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 ([RFC2119]).

Top      ToC       Page 4 
1.1.  Scope of This Document

   This document provides requirements specific to Layer 3 Virtual
   Private Networks (L3VPN). (Requirements that are generic to L2 and L3
   VPNs are contained in [RFC3809].)

   This document identifies requirements that may apply to one or more
   individual approaches that a Service Provider may use to provision a
   Layer 3 (e.g., IP) VPN service.  It makes use of the terminology and
   common components for Layer 3 VPNs as defined in [L3VPN-FR] and of
   the generic VPN terminology defined in
   [PPVPN-TERM].

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

   Technical approaches targeted by this document include the network-
   based (PE-based) L3VPN category (aggregated routing VPNs [2547bis]
   and virtual routers [PPVPN-VR]) and the CE-based L3VPNs category
   [CE-PPVPN][IPSEC-PPVPN].  The document distinguishes L3VPN categories
   as to where the endpoints of tunnels exist, as detailed in the L3VPN
   framework document [L3VPN-FR].  Terminology describing whether
   equipment faces a customer or the service provider network is used to
   define the various types of L3VPN solutions.

   This document is intended as a "checklist" of requirements, providing
   a consistent way to evaluate and document how well each approach
   satisfies specific requirements.  The applicability statement
   documents for each approach should present the results of this
   evaluation.  This document is not intended to compare one approach to
   another.

   This document provides requirements from several points of view.  It
   begins with some considerations from a point of view common to
   customers and service providers not covered in the generic provider
   provisioned VPN requirement document [RFC3809], continues with a
   customer perspective, and concludes with specific needs of a Service
   Provider (SP).

   The following L3VPN deployment scenarios are considered within this
   document:

   1.  Internet-wide: VPN sites attached to arbitrary points in the
       Internet.

Top      ToC       Page 5 
   2.  Single SP/single AS: VPN sites attached to the network of a
       single provider within the scope of a single AS.

   3.  Single SP/multiple ASes: VPN sites attached to the network of a
       single provider consisting of multiple ASes.

   4.  Cooperating SPs: VPN sites attached to networks of different
       providers that cooperate with each other to provide the VPN
       service.

   The above deployment scenarios have many requirements in common.
   These include SP requirements for security, privacy, manageability,
   interoperability, and scalability, including service provider
   projections for number, complexity, and rate of change of customer
   VPNs over the next several years.  When requirements apply to a
   specific deployment scenario, the above terminology is used to state
   the context of those particular requirements.

1.2.  Outline

   The outline of the rest of the document is as follows:  Section 2
   lists the contributing authors.  Section 3 provides definitions of
   terms and concepts.  Section 4 provides requirements common to both
   customers and service providers that are not covered in the generic
   provider provisioned VPN requirement document [RFC3809].  Section 5
   states requirements from a customer perspective.  Section 6 states
   network requirements from a service provider perspective.  Section 7
   states service provider management requirements.  Section 8 describes
   security considerations.  Section 9 lists acknowledgments.  Section
   10 provides a list of references cited herein.  Section 11 lists the
   authors' addresses.

2.  Contributing Authors

   This document is the combined effort of the two co-editors and the
   following contributing authors:

      Luyuan Fang
      Ananth Nagarajan
      Junichi Sumimoto
      Rick Wilder

3.  Definitions

   This section provides the definition of terms and concepts used
   throughout the document.  Terminology used herein is taken from
   [PPVPN-TERM] and [L3VPN-FR].

Top      ToC       Page 6 
3.1.  Virtual Private Network

   "L3 Virtual Private Network" (L3VPN) refers to the L3 communication
   between a set of sites making use of a shared network infrastructure.

   "Provider Provisioned VPN" (PPVPN) refers to VPNs for which the
   service provider participates in management and provisioning of the
   VPN.

3.2.  Users, Sites, Customers, and Agents

   User: A user is an entity (e.g., a human being using a host, a
   server, or a system) authorized to use a VPN service.

   Site: A site is a set of users that have mutual L3 (i.e., IP)
   reachability without use of a specific service provider network.  A
   site may consist of a set of users that are in geographic proximity.
   Note that a topological definition of a site (e.g., all users at a
   specific geographic location) may not always conform to this
   definition.  For example, two geographic locations connected via
   another provider's network would also constitute a single site as
   communication between the two locations does not involve the use of
   the service provider offering the L3 VPN service.

   Customer: A single organization, corporation, or enterprise that
   administratively controls a set of sites.

   Agent: A set of users designated by a customer who has the
   authorization to manage a customer's VPN service offering.

3.3.  Intranets, Extranets, and VPNs

   Intranet: An intranet restricts communication to a set of sites that
   belong to one customer.  An example is branch offices at different
   sites that require communication with 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 extranets include multiple companies
   cooperating in joint software development, a service provider having
   access to information from the vendors' corporate sites, different
   companies, or universities participating in a consortium.  An
   extranet often has further restrictions on reachability, for example,
   at a host and individual transport level.

Top      ToC       Page 7 
   Note that an intranet or extranet can exist across a single service
   provider network with one or more ASes, or across multiple service
   provider networks.

   L3 Virtual Private Network (L3VPN): An alternative definition of VPN
   refers to a specific set of sites that have been configured to allow
   communication as either an intranet or an extranet.  Note that a site
   is a member of at least one VPN and may be a member of many VPNs.

3.4.  Networks of Customer and Provider Devices

   L3VPNs are composed of the following types of devices.

   Customer Edge (CE) device: A CE device faces the users at a customer
   site.  The CE has an access connection to a PE device.  It may be a
   router or a switch that allows users at a customer site to
   communicate over the access network with other sites in the VPN.  In
   a CE-based L3VPN, as intended in this document (provider-provisioned
   CE-based VPN), the service provider manages (at least partially) the
   CE device.

   Provider Edge (PE) device: A PE device faces the provider network on
   one side and attaches via an access connection over one or more
   access networks to one or more CE devices.  It participates in the
   Packet Switched Network (PSN) in performing routing and forwarding
   functions.

   Note that the definitions of Customer Edge and Provider Edge do not
   necessarily describe the physical deployment of equipment on customer
   premises or a provider point of presence.

   Provider (P) device: A device within a provider network that
   interconnects PE (or other P) devices but does not have any direct
   attachment to CE devices.  The P router does not keep VPN state and
   is VPN unaware [PPVPN-TERM].

   Packet Switched Network (PSN): A (IP or MPLS [RFC3031]) network
   through which the tunnels supporting the VPN services are set up
   [PPVPN-TERM].

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

3.5.  Access Networks, Tunnels, and Hierarchical Tunnels

   VPNs are built between CEs by using access networks, tunnels, and
   hierarchical tunnels across a PSN.

Top      ToC       Page 8 
   Access connection: An access connection provides connectivity between
   a CE and a PE.  This includes dedicated physical circuits, virtual
   circuits (such as Frame Relay), ATM, Ethernet (V)LAN, or IP tunnels
   (e.g., IPsec, L2TP [RFC2661]).

   Access network: An access network provides access connections between
   CE and PE devices.  It may be a TDM network, an L2 network (e.g., FR,
   ATM, and Ethernet), or an IP network over which access is tunneled
   (e.g., by using L2TP).

   Tunnel: A tunnel between two entities is formed by encapsulating
   packets within another encapsulating header for the purposes of
   transmission between those two entities in support of a VPN
   application.  Examples of protocols commonly used for tunneling are
   GRE, IPsec, IP-in-IP tunnels, and MPLS.

   Hierarchical Tunnel: Encapsulating one tunnel within another forms a
   hierarchical tunnel.  The innermost tunnel protocol header defines a
   logical association between two entities (e.g., between CEs or PEs)
   [VPNTUNNEL].  Note that the tunneling protocols need not be the same
   at different levels in a hierarchical tunnel.

3.6.  Use of Tunnels and Roles of CE and PE in L3 VPNs

   This section summarizes the points where tunnels terminate and the
   functions implemented in the CE and PE devices that differentiate the
   two major categories of L3VPNs for which requirements are stated,
   namely PE-based and CE-based L3VPNs.  See the L3VPN framework
   document for more detail [L3VPN-FR].

3.6.1.  PE-Based L3VPNs and Virtual Forwarding Instances

   In a PE-based L3VPN 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 forwards user data packets
   based on information in the IP layer header, such as an IPv4 or IPv6
   destination address.  The CE sees the PE as a layer 3 device such as
   an IPv4 or IPv6 router.

   Virtual Forwarding Instance (VFI): In a PE-based L3VPN service, the
   PE contains a VFI for each L3 VPN that it serves.  The VFI terminates
   tunnels for interconnection with other VFIs and also terminates
   access connections for accommodating CEs.  VFI contains information
   regarding how to forward data received over the CE-PE access
   connection to VFIs in other PEs supporting the same L3VPN.  The VFI
   includes the router information base and the forwarding information
   base for an L3VPN [L3VPN-FR].  A VFI enables router functions
   dedicated to serving a particular VPN, such as separation of

Top      ToC       Page 9 
   forwarding and routing and support for overlapping address spaces.
   Routing protocols in the PEs and the CEs interact to populate the
   VFI.

   The following narrative and figures provide further explanation of
   the way PE devices use tunnels and hierarchical tunnels.  Figure 1.1
   illustrates the case where a PE uses a separate tunnel for each VPN.
   As shown in the figure, the tunnels provide communication between the
   VFIs in each of the PE devices.

                  +----------+              +----------+
   +-----+        |PE device |              |PE device |        +-----+
   | CE  |        |          |              |          |        | CE  |
   | dev | Access | +------+ |              | +------+ | Access | dev |
   | of  |  conn. | |VFI of| |    Tunnel    | |VFI of| |  conn. | of  |
   |VPN A|----------|VPN A |==================|VPN A |----------|VPN A|
   +-----+        | +------+ |              | +------+ |        +-----+
                  |          |              |          |
   +-----+ Access | +------+ |              | +------+ | Access +-----+
   |CE   |  conn. | |VFI of| |    Tunnel    | |VFI of| |  conn. | CE  |
   | dev |----------|VPN B |==================|VPN B |----------| dev |
   | of  |        | +------+ |              | +------+ |        | of  |
   |VPN B|        |          |              |          |        |VPN B|
   +-----+        +----------+              +----------+        +-----+

        Figure 1.1.  PE Usage of Separate Tunnels to Support VPNs

   Figure 1.2 illustrates the case where a single hierarchical tunnel is
   used between PE devices to support communication for VPNs.  The
   innermost encapsulating protocol header provides the means for the PE
   to determine the VPN for which the packet is directed.

                  +----------+              +----------+
   +-----+        |PE device |              |PE device |        +-----+
   | CE  |        |          |              |          |        | CE  |
   | dev | Access | +------+ |              | +------+ | Access | dev |
   | of  |  conn. | |VFI of| |              | |VFI of| |  conn. | of  |
   |VPN A|----------|VPN A | | Hierarchical | |VPN A |----------|VPN A|
   +-----+        | +------+\|   Tunnel     |/+------+ |        +-----+
                  |          >==============<          |
   +-----+ Access | +------+/|              |\+------+ | Access +-----+
   | CE  |  conn. | |VFI of| |              | |VFI of| |  conn. | CE  |
   | dev |----------|VPN B | |              | |VPN B |----------| dev |
   | of  |        | +------+ |              | +------+ |        | of  |
   |VPN B|        |          |              |          |        |VPN B|
   +-----+        +----------+              +----------+        +-----+

   Figure 1.2. PE Usage of Shared Hierarchical Tunnels to Support VPNs

Top      ToC       Page 10 
3.6.2.  CE-Based L3VPN Tunnel Endpoints and Functions

   Figure 1.3 illustrates the CE-based L3VPN reference model.  In this
   configuration, typically a single level of tunnel (e.g., IPsec)
   terminates at pairs of CEs.  Usually, a CE serves a single customer
   site, and therefore the forwarding and routing is physically separate
   from all other customers.  Furthermore, the PE is not aware of the
   membership of specific CE devices to a particular VPN.  Hence, the
   VPN functions are implemented with provisioned configurations on the
   CE devices, and the shared PE and P network is used to only provide
   the routing and forwarding that supports the tunnel endpoints on
   between CE devices.  The tunnel topology connecting the CE devices
   may be a full or partial mesh, depending on VPN customer requirements
   and traffic patterns.

       +---------+  +--------------------------------+  +---------+
       |         |  |                                |  |         |
       |         |  |                 +------+     +------+  : +------+
   +------+ :    |  |                 |      |     |      |  : |  CE  |
   |  CE  | :    |  |                 |  P   |     |  PE  |  : |device|
   |device| :  +------+    Tunnel     |router|     |device|  : |  of  |
   |  of  |=:================================================:=|VPN  A|
   |VPN  A| :  |      |               +------+     +------+  : +------+
   +------+ :  |  PE  |                              |  |    :    |
   +------+ :  |device|                              |  |    :    |
   |  CE  | :  |      |           Tunnel           +------+  : +------+
   |device|=:================================================:=|  CE  |
   |  of  | :  +------+                            |  PE  |  : |device|
   |VPN  B| :    |  |                              |device|  : |  of  |
   +------+ :    |  |  +----------+   +----------+ |      |  : |VPN  B|
       |    :    |  |  | Customer |   | Network  | +------+  : +------+
       |Customer |  |  |management|   |management|   |  |    :    |
       |interface|  |  | function |   | function |   |  |Customer |
       |         |  |  +----------+   +----------+   |  |interface|
       |         |  |                                |  |         |
       +---------+  +--------------------------------+  +---------+
       | Access  |  |<-------- SP network(s) ------->|  | Access  |
       | network |  |                                |  | network |

                        Figure 1.3. CE-Based L3VPN

3.7.  Customer and Provider Network Management

   Customer Network Management Function: A customer network management
   function provides the means for a customer agent to query or
   configure customer-specific information, or to receive alarms
   regarding his or her VPN.  Customer-specific information includes
   data related to contact, billing, site, access network, IP address,

Top      ToC       Page 11 
   and routing protocol parameters.  It may use a combination of
   proprietary network management system, SNMP manager, or directory
   service (e.g., LDAP [RFC3377] [RFC2251]).

   Provider Network Management Function: A provider network management
   function provides many of the same capabilities as a customer network
   management system across all customers.  This would not include
   customer confidential information, such as keying material.  The
   intent of giving the provider a view comparable to that of the
   customer is to aid in troubleshooting and problem resolution.  Such a
   system also provides the means to query, configure, or receive alarms
   regarding any infrastructure supporting the L3VPN service.  It may
   use a combination of proprietary network management system, SNMP
   manager, or directory service (e.g., LDAP [RFC3377] [RFC2251]).

4.  Service Requirements Common to Customers and Service Providers

   Many of the requirements that apply to both the customer and the
   provider and are of an otherwise general nature, or that apply to
   both L2 and L3VPNs, are described in [RFC3809].  This section
   contains requirements that are not covered in [RFC3809] and that are
   specific to L3VPNs.

4.1.  Isolated Exchange of Data and Routing Information

   A mechanism must be provided for isolating the distribution of
   reachability information to only those sites associated with a VPN.

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

   A means must be provided to constrain or isolate the distribution of
   addressed data to only those VPN sites determined by either routing
   data and/or configuration.

   A single site shall be capable of being in multiple VPNs.  The VPN
   solution must ensure that traffic is exchanged only with sites in the
   same VPN.

   The internal structure of a VPN should not be advertised or
   discoverable from outside that VPN.

   Note that isolation of forwarded data 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], [MPLSSEC].

Top      ToC       Page 12 
4.2.  Addressing

   IP addresses must be unique within the set of sites reachable from
   the VPNs of which a particular site is a member.

   A VPN solution must support IPv4 and IPv6 as both the encapsulating
   and encapsulated protocol.

   If a customer has private or non-unique IP addresses, then a VPN
   service SHOULD be capable of translating such customer private or
   non-unique IP addresses for communicating with IP systems having
   public addresses.

4.3.  Quality of Service

   To the extent possible, L3VPN QoS should be independent of the access
   network technology.

4.3.1.  QoS Standards

   A non-goal of the L3VPN WG effort (as chartered) is the development
   of new protocols or extension of existing ones.  An L3VPN shall be
   able to support QoS in one or more of the following already defined
   modes:

      - Best Effort  (mandatory support for all L3VPN types)
      - Aggregate CE Interface Level QoS ("hose" level QoS)
      - Site-to-site ("pipe" level QoS)
      - Intserv (i.e., RSVP) signaled
      - Diffserv marked
      - Across packet-switched access networks

   Note that all cases involving QoS may require that the CE and/or PE
   perform shaping and/or policing.

   L3VPN CEs should be capable of supporting integrated services
   (Intserv) for certain customers in support of session applications,
   such as switched voice or video.  Intserv-capable CE devices shall
   support the following Internet standards:

   -  Resource reSerVation Protocol (RSVP) [RFC2205]
   -  Guaranteed Quality of Service providing a strict delay bound
      [RFC2212]
   -  Controlled Load Service providing performance equivalent to that
      of an unloaded network [RFC2211]

Top      ToC       Page 13 
   L3VPN CE and PE should be capable of supporting differentiated
   service (Diffserv).  Diffserv-capable L3VPN CE and PE shall support
   the following per hop behavior (PHB) [RFC2475] types:

   -  Expedited Forwarding (EF) - The departure rate of an aggregate
      class of traffic from a device that must equal or exceed a
      configured rate [RFC3246].

   -  Assured Forwarding (AF) - A means for a provider Diffserv (DS)
      domain to offer different levels of forwarding assurances for IP
      packets received from a customer DS domain.  Four AF classes are
      defined, where each AF class implies allocation in each DS node of
      a certain amount of forwarding resources (e.g., buffer space and
      bandwidth) [RFC2597].

   A CE or PE device supporting an L3VPN service may classify a packet
   for a particular Intserv or Diffserv service based on one or more of
   the following IP header fields: protocol ID, source port number,
   destination port number, destination address, or source address.

   For a specifiable set of Internet traffic, L3VPN devices should
   support Random Early Detection (RED) to provide graceful degradation
   in the event of network congestion.

4.3.2.  Service Models

   A service provider must be able to offer QoS service to a customer
   for at least the following generic service types: managed-access VPN
   service or edge-to-edge QoS VPN service [RFC3809].  More detail
   specific to L3VPNs is provided below.

   A managed-access L3VPN service provides QoS on the access connection
   between the CE and the PE.  For example, diffserv would be enabled
   only on the CE router and the customer-facing ports of the PE router.
   Note that this service would not require Diffserv implementation in
   the SP backbone.  The SP may use policing for inbound traffic at the
   PE.  The CE may perform shaping for outbound traffic.  Another
   example of a managed-access L3VPN service is when the SP performs the
   packet classification and diffserv marking.  An SP may provide
   several packet classification profiles that customers may select or
   may offer custom profiles based on customer specific requirements.
   In general, more complex QoS policies should be left to the customer
   for implementation.

   An edge-to-edge QoS VPN service provides QoS from edge device to edge
   device.  The edge device may be either PE or CE, depending on the
   service demarcation point between the provider and the customer.
   Such a service may be provided across one or more provider backbones.

Top      ToC       Page 14 
   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.

4.4.  Service-Level Specification and Agreements

   A generic discussion of SLAs is provided in [RFC3809].  Additionally,
   SLS measurements for quality based on the DiffServ scheme SHOULD be
   based on the following classification:

       -  A Point-to-Point SLS [Y.1311.1], sometimes also referred to as
          the "Pipe" model, defines traffic parameters in conjunction
          with the QoS objectives for traffic exchanged between a pair
          of VPN sites (i.e., points).  A Point-to-Point SLS is
          analogous to the SLS typically supported over point-to-point
          Frame Relay or ATM PVCs or an edge-to-edge MPLS tunnel.  The
          set of SLS specifications to all other reachable VPN sites
          would define the overall Point-to-Point SLS for a specific
          site.

       -  A Point-to-Cloud SLS [Y.1311.1], sometimes also referred to 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 (a case not covered by this SLS is where
          flows originating from multiple sources may congest the
          interface toward a specific site).

   Traffic parameters and actions SHOULD be defined for packets to and
   from the demarcation between the service provider and the site.  For
   example, policing may be defined on ingress, and shaping on egress.

4.5.  Management

   An SP and its customers MUST be able to manage the capabilities and
   characteristics of their VPN services.  To the extent possible,
   automated operations and interoperability with standard management
   platforms SHOULD be supported.

Top      ToC       Page 15 
   The ITU-T Telecommunications Management Network (TMN) model has the
   following generic requirements structure:

   O  Engineer, deploy, and manage the switching, routing, and
      transmission resources supporting the service, from a network
      perspective (network element management).

   O  Manage the VPN networks deployed over these resources (network
      management).

      o  Manage the VPN service (service management).
      o  Manage the VPN business, mainly provisioning administrative and
         accounting information related to the VPN service customers
         (business management).

   Service management should include the TMN 'FCAPS' functionalities, as
   follows: Fault, Configuration, Accounting, Provisioning, and
   Security, as detailed in section 7.

4.6.  Interworking

   Interworking scenarios among different solutions providing L3VPN
   services is highly desirable.  See the L3VPN framework document for
   more details on interworking scenarios [L3VPN-FR].  Interworking
   SHOULD be supported in a scalable manner.

   Interworking scenarios MUST at least consider traffic and routing
   isolation, security, QoS, access, and management aspects.  This
   requirement is essential of network migration, to ensure service
   continuity among sites belonging to different portions of the
   network.



(page 15 continued on part 2)

Next RFC Part