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