One document matched: draft-ietf-ppvpn-requirements-00.txt
INTERNET DRAFT M. Carugi
Internet Engineering Task Force France Telecom
Document: D. McDysan
draft-ietf-ppvpn-requirements-00.txt WorldCom
February 2001 (Co-Editors)
Category: Informational L. Fang
Expires: August 2001 AT&T
F. Johansson
Telia
Ananth Nagarajan
Sprint
J. Sumimoto
NTT
R. Wilder
Zephion Networks
Service requirements for Provider Provisioned Virtual Private
Networks :
<draft-ietf-ppvpn-requirements-00.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 nbvpn@bbo.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
Carugi et al 1
Service requirements for PPVPNs February, 2001
This document provides requirements for Provider Provisioned Virtual
Private Networks (PPVPNs). It identifes requirements applicable to a
number of individual approaches that a Service Provider may use for
the provisioning of a VPN service. This document expresses a service
provider perspective, based upon past experience of IP-based service
offerings and the ever evolving needs of the customers of such
services. Toward this end, it first defines terminology and states
general requirements. Detailed requirements are expressed from a
customer as well as a service provider perspective.
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 Provider Provisioned Virtual Private Network ...................6
2.2 Customers, Sites, Users, and Subscribers .......................6
2.3 Intranets and Extranets ........................................7
2.4 Layered VPN Services ...........................................7
2.5 Layer 2 VPN Service ............................................7
2.6 Layer 3 VPN Service ............................................8
2.7 Customer Equipment (CE) Based ..................................8
2.7.1 Reference Model.............................................8
2.8 Network Based ..................................................9
2.8.1 Reference Model............................................10
2.9 VPN Tunnels ...................................................12
3 General Requirements............................................12
3.1 Topology ......................................................12
3.2 Exchange of Data and Routing Information ......................13
3.3 Addressing ....................................................13
3.4 Security ......................................................13
3.4.1 User data security.........................................13
3.4.2 Routing data security......................................13
3.4.3 Access control.............................................13
3.4.4 VPN isolation..............................................14
3.5 Management ....................................................14
3.6 Interoperability (TEXT MAINLY DERIVED FROM [Y.1311.1]) ........14
4 Customer Requirements...........................................14
4.1 VPN Membership (Intranet/Extranet) ............................14
4.2 Service Provider Independence .................................15
4.3 Addressing ....................................................15
4.4 Traffic Types .................................................15
4.5 Routing Protocol Support ......................................15
4.6 SLA/SLS .......................................................15
4.7 Management ....................................................16
Carugi et al Informational - Expires August 2001 2
Service requirements for PPVPNs February, 2001
4.8 Security/Integrity [Y.1311.1] .................................17
4.9 Migration Impact ..............................................18
4.10 Network Access ................................................18
4.10.1 Physical/Link Layer Technology.............................18
4.10.2 Remote Access..............................................18
4.10.3 Sharing of the Access Network..............................18
4.10.4 Access Connectivity Multi-homing, Backdoor, Shortcut.......18
4.11 Service Access ................................................20
4.11.1 Internet Access............................................20
4.11.2 Hosting, Application Service Provider......................21
4.11.3 Other Services.............................................21
4.12 Hybrid VPN Scenarios ..........................................21
5 Service Provider Requirements...................................21
5.1 Scalability ...................................................22
5.2 Addressing ....................................................23
5.3 Identifiers ...................................................24
5.4 Learning VPN Membership .......................................24
5.5 Service Level Agreements and Specifications ...................24
5.6 QoS ...........................................................26
5.6.1 A Service Deployment Perspective...........................26
5.6.2 A Standards-Based Approach.................................27
5.6.3 Diffserv-Specific Requirements.............................29
5.7 Resource Control ..............................................29
5.8 Inter-AS (SP)VPNs .............................................29
5.8.1 Routing Protocols..........................................30
5.8.2 Management.................................................30
5.8.3 Bandwidth and Qos Brokering................................30
5.8.4 Security Considerations....................................31
5.9 Isolation (Traffic, Processing Resources) .....................31
5.10 Tunneling Mechanism Independence and Selection ...............31
5.11 Backbone Technology Independence .............................32
5.12 Protection, Restoration ......................................32
5.13 PPVPN Wholesale ..............................................33
5.14 Management ...................................................33
5.14.1 Configuration Management..................................34
5.14.2 Service monitoring........................................36
5.14.3 VPN management solutions..................................39
5.15 Migration Support .............................................40
5.16 Isolation, Security, Authentication and Identification .......40
5.16.1 VPN isolation.............................................40
5.16.2 VPN user identification...................................41
5.16.3 VPN user authentication...................................42
5.16.4 Securing the flow.........................................42
5.16.5 Peer identification.......................................42
5.16.6 Peer authentication.......................................43
5.16.7 Site protection...........................................43
5.17 Provisioning Routing [Y.1311.1] ..............................44
5.18 Provisioning Network Access ..................................44
5.19 Provisioning Security Services ...............................44
5.20 Provisioning VPN Parameters ..................................44
5.21 Provisioning Value-Added Service Access ......................44
Carugi et al Informational - Expires August 2001 3
Service requirements for PPVPNs February, 2001
5.21.1 IP Networking Services....................................45
5.21.2 Internet access...........................................45
5.22 Provisioning Hybrid VPN Services .............................45
5.23 Interoperability .............................................45
6 Security Considerations.........................................45
7 Acknowledgements................................................46
8 References......................................................46
9 Authors" address................................................47
Carugi et al Informational - Expires August 2001 4
Service requirements for PPVPNs February, 2001
1 Introduction
NOTE: EDITOR"S NOTES, ISSUES AND AREAS REQUIRING FURTHER WORK ARE
INDICATED IN ALL CAPS.
1.1 Scope of this document
This document provides requirements for 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 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
PPVPNs defined in [PPVPN-FR].
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.
The charter of the PPVPN working group defines at least three types
of PPVPNs: BGP-VPNs (e.g. RFC 2547), virtual routers and port-based
VPNs (i.e., where the SP provides a Layer 2 interface, such as Frame
Relay or ATM, to the VPN customer, while using IP-based mechanisms in
the provider infrastructure to improve scalability and
configurability over traditional L2 networks). The approach followed
in this document distinguishes PPVPN types as to where the endpoints
of tunnels exist and whether the service provided is layer 2 or layer
3. Terminology regarding whether equipment faces a customer or the
service provider network is used to define the various types of PPVPN
solutions. This requirements document summarizes the reference model
from framework document [PPVPN-FR]for the convenience of readers.
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 a specific requirement. The relevant
documents for each individual approach should document the results of
this evaluation.
This document first provides general requirements, followed by
requirements from a customer perspective, and concludes with
requirements from a Service Provider (SP) perspective. These
requirements provide high level PPVPN features expected by a 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 SP" s
projections for number, complexity, and rate of change of customer
VPNs over the next several years.
Carugi et al Informational - Expires August 2001 5
Service requirements for PPVPNs February, 2001
1.2 Outline
The outline of the rest of this document is as follows. Section 2
defines terminology and summarizes the ppvpn reference model. Section
3 provides general requirements. Section 4 states requirements from a
customer perspective. Section 5 states requirements from a service
provider perspective. Section 6 describes security considerations.
Section 7 lists acknowledgements. Section 8 provides a list of
references cited herein. Section 9 lists the author"s addresses.
2 Definitions
NOTE: DEFINITIONS IN THIS SECTION WERE TAKEN FROM PREVIOUS TEXT, THE
FRAMEWORK DOCUMENT AND THE NOTES CAPTURED BY THE DESIGN TEAM.
2.1 Provider Provisioned Virtual Private Network
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
interconnection of customer sites, making use of a shared network
infrastructure. Multiple sites of a private network may therefore be
interconnected via the public infrastructure, in order to facilitate
the operation of the private network. The logical structure of the
VPN, such as addressing, 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.
The taxonomy of PPVPN types has two principal dimensions: whether the
service provided to the customer is layer 2 or layer 3, and whether
the tunnels that provide the service either terminate on Customer
facing Equipment (CE), or on "Network-based" Provider Edge (PE)
equipment. Note that the definitions of Customer Equipment and
Provider Edge do not necessarily map to the physical deployment of
equipment on customer premises or a provider point of presence.
2.2 Customers, Sites, Users, and Subscribers
THE FOLLOWING ARE TENTATIVE DEFINITIONS TAKEN FROM [VPN-
NEEDS](ALIGNMENT OF THE DOCUMENT TO THESE TENTATIVE DEFINITIONS HAS
NOT BEEN RIGOROUSLY PURSUED)
Customer = subscriber.
Subscriber : A subscriber (or a customer) is a legal representative
who has the (legal) ability to subscribe to a service offering.
User : A user is an entity (a human being or a process, from a
general perspective) who has been named by a subscriber and
Carugi et al Informational - Expires August 2001 6
Service requirements for PPVPNs February, 2001
appropriately identified by a service provider, so that he might
benefit from a service according to his associated rights and duties.
The definition of site is taken from [RFC 2547], as follows:
From the perspective of a particular backbone network, a set of IP
systems constitutes a site if those systems have mutual IP
interconnectivity, and communication between them occurs without use
of the backbone. In general, a site will consist of a set of systems
which are in geographic proximity. However, this is not universally
true; two geographic locations connected via a leased line, over
which OSPF is running, will constitute a single site, because
communication between the two locations does not involve the use of
the backbone.
2.3 Intranets and Extranets
An intranet defines connectivity between sites in the same
organization. This is the simplest and most common scenario. In this
scenario, a VPN is formed between different sites belonging to the
same organization. For example, this scenario could be envisioned as
one where different branch offices are interconnected and/or also
connect to the headquarters. This is the minimum/mandatory scenario
that needs to be supported by any VPN architecture. All other service
deployment scenarios require certain modifications/extensions to the
basic intranet architecture.
An extranet defines connectivity between sites across multiple
organizations. In an extranet scenario, two or more organizations
have access to a limited number 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 and
universities participating in a consortium, etc. An extranet can
exist across a single service provider backbone or across multiple
backbones or autonomous systems. The main difference between an
extranet and an intranet is the existence of some kind of an access
control mechanism at the interconnection between different
organizations. This access control can be implemented by a firewall,
access lists on routers or similar mechanisms to apply policy-based
access control to transit traffic. The access control mechanism may
be achieved using separate devices or may be integrated into the PE
device.
2.4 Layered VPN Services
A PPVPN must provide a layer 2 VPN service, a layer 3 VPN service, or
both to a set of customer sites.
2.5 Layer 2 VPN Service
In a layer 2 VPN service, a customer site receives datalink layer
(i.e., layer 2) service from the SP. The CE and PE are adjacent to
each other at the datalink layer and not at the IP layer. A PE
performs forwarding of customer data packets based on information in
Carugi et al Informational - Expires August 2001 7
Service requirements for PPVPNs February, 2001
the packets" datalink layer headers, such as a frame relay DLCI or
802.1q VLAN tag. That is, the CE sees the PE as a layer 2 device such
as a FR switch or an Ethernet VLAN switch.
Initial protocol proposals have been made to define how an IP-
controlled MPLS network could provide a layer 2 VPN service. See [L2
VPN] and [L2 MPLS] for more information.
2.6 Layer 3 VPN Service
In a layer 3 VPN service, a customer site receives IP layer (i.e.,
layer 3) service from the SP. The CE and PE are adjacent to each
other at the datalink layer and the IP layer. The PE performs
forwarding of customer 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.
2.7 Customer Equipment (CE) Based
In a CE-based VPN, the tunnels terminate at the CE, as detailed in
the reference model described below. The CE faces the network at
customer site, but may or may not be located on the customer
premises. The PE may optionally distinguish between packets that
belong to the PPVPN based upon the VPN tunnel, and not based on the
user data packet header. The provider may or may not manage the
customer equipment.
Examples of a CE-based layer 3 VPN service are a SP managed IPsec
router, or a customer-managed router tunneled over an ISP network.
Examples of a CE-based layer 2 VPN service are a managed router
connected, or a customer-managed router connected via layer 2
connections.
The above CE-based "customer-managed router" scenarios are outside of
the PPVPN WG charter.
2.7.1 Reference Model
Figure 2.1 shows the reference model for SP managed CE-based VPN. The
entities in the reference model are described below.
NOTE: MANY OF THESE TERMS AND DEFINITIONS OVERLAP WITH THE NEXT
SECTION ON NETWORK-BASED VPNS.
o Customer edge (CE) device: This device is provisioned and possibly
managed as well by the service provider. For example, it may support
IPsec.
o Provider edge (PE) router: It is a router without any VPN specific
functionality.
o SP networks: IP network + CE management function.
Carugi et al Informational - Expires August 2001 8
Service requirements for PPVPNs February, 2001
o Access network (See section 4.10)
o Tunnel: A tunnel is a connection between CE routers. (See section
2.9)
o Device for customer management (See section 3.5)
o Device for network management (See section 5.14)
+---------+ +-----------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | VPN | PE | | PE | : |device|
|device| : +------+ Tunnel |router| |router| : | of |
| of |=:===================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |router| VPN | | : |
| CE | : | | Tunnel +------+ : +------+
|device|=:===================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | | | |router| : | of |
+------+ : | | +------+-----+ +------+----+ | | : |VPN B|
| : | | | Device for | |Device for | +------+ : +------+
|Customer | | | customer | | network | | | : |
|interface| | | management | |management | | |Customer |
| | | +------------+ +-----------+ | |interface|
| | | | | |
+---------+ +-----------------------------------+ +---------+
| Access | |<---------- SP network(s) -------->| | Access |
| network | | | | network |
Figure 2.1: Reference model for SP managed CE-based VPN
2.8 Network Based
In a Network-based VPN, the tunnels terminate at the PE, as detailed
in the reference model described below. The PE faces the service
provider network, but may or may not be located in a service provider
point of presence. The PE distinguishes between packets that belong
to the PPVPN based on information in the user data packet at L1, L2,
and/or L3. The service provider always manages the PE equipment.
The term "Network-Based VPN" is also defined by the ITU-T in
Y.1311.1, as follows. "A network-based IP VPN provides a layer-3
service to customers. A customer site may be connected to the
Service Provider network-based IP VPN, and the IP VPN takes care of
routing packets to the correct customer destination. With a network-
based IP VPN the Provider edge routers are responsible for learning
Carugi et al Informational - Expires August 2001 9
Service requirements for PPVPNs February, 2001
and distributing among themselves the customer layer-3 reachability
information."
An example of a Network-based layer 2 VPN is provision of a FR or ATM
service over an MPLS-based, IP controlled service provider backbone
[L2 VPN], [L2 MPLS].
Examples of a Network-based layer 3 VPN are the BGP/MPLS VPN [RFC
2547] or virtual routers [2917bis], [VPN-VR].
2.8.1 Reference Model
Figure 2.2 shows the reference model for network-based VPN and Figure
2.3 shows relationship between entities in the reference model. The
entities in the reference model are described below.
? Customer edge (CE) device: A CE device is a device on the customer
site which has an access connection to a PE router. It may be a
router, host, or switch located at the edge of a user site.
? P Router: A router within a provider network which is used to
interconnect PE routers, but which does not have any VPN state and
does not have any direct attachment to CE devices.
? Provider Edge (PE) router: A PE router is attached via an access
connection to one or more CE devices. In the context of supporting
VPNs, a PE router implements one or more VFIs and maintains per-VPN
state. (Note that access connections are terminated by VFIs from
the functional point of view.)
? SP networks: An SP network is a network administered by a single
service provider.
? Access connection: An access connection represents an isolated L2
connectivity between a CE device and a PE router. This includes
dedicated physical circuits, logical circuits (such as Frame Relay
and ATM), plus IP tunnels (eg, using IPsec, L2TP).
? Access network: An access network provides access connections
between CE devices and PE routers. It may be a TDM network, L2
network (e.g. FR, ATM, and Ethernet), or IP network over which
access is tunneled (eg using L2TP [RFC2661]).
? VPN Tunnel: A VPN tunnel is a logical link between two entities
which is created by encapsulating packets within an encapsulating
header for purpose of transmission between those two entities for
support of VPNs.
VFIs are typically interconnected via (per-VPN) tunnels. This is
illustrated in figure 2.3. Another example of a tunnel is a
connection between PE routers.
Carugi et al Informational - Expires August 2001 10
Service requirements for PPVPNs February, 2001
Multiple tunnels at one level may be hierarchically multiplexed into
a single tunnel at another level. For example, multiple per-VPN
tunnels may be multiplexed into a single PE to PE tunnel.
+---------+ +-----------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | VPN | PE | VPN | PE | : |device|
|device| : +------+ Tunnel : |router| :Tunnel |router| : | of |
| of |-:--| |========:===| |===:=======| |--:-|VPN A|
|VPN A| : | | : +------+ : +------+ : +------+
+------+ : | PE | : : | | : |
+------+ : |router| Network interface | | : |
| CE | : | | : +------+ : +------+
|device|-:--| |================:==============| |--:-| CE |
| of | : +------+ VPN Tunnel | PE | : |device|
|VPN B| : | | | | |router| : | of |
+------+ : | | +------+-----+ +------+----+ | | : |VPN B|
| : | | | Device for | |Device for | +------+ : +------+
|Customer | | | customer | | network | | | : |
|interface| | | management | |management | | |Customer |
| | | +------------+ +-----------+ | |interface|
| | | | | |
+---------+ +-----------------------------------+ +---------+
| Access | |<---------- SP network(s) -------->| | Access |
| network | | single or multiple SP domains | | network |
Figure 2.2: Reference model for network-based VPN.
+----------+ +----------+
+-----+ |PE router | |PE router | +-----+
| CE | | | +-------------+ | | | CE |
| dev | Access | +------+ | : : | +------+ | Access | dev |
| of | conn. | |VFI of| | : VPN Tunnel : | |VFI of| | conn. | of |
|VPN A|----------|VPN A |---------------------|VPN A |----------|VPN A|
+-----+ | +------+ | : : | +------+ | +-----+
| | : : | |
+-----+ Access | +------+ | : : | +------+ | Access +-----+
| CE | conn. | |VFI of| | : VPN Tunnel : | |VFI of| | conn. | CE |
| dev |----------|VPN B |---------------------|VPN B |----------| dev |
| of | | +------+ | : : | +------+ | | of |
|VPN B| | | +-------------+ | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 2.3: Relationship between entities in reference model.
? VPN Forwarding Instance (VFI): A VFI is a logical entity that
resides in a PE, that includes the router information base and
Carugi et al Informational - Expires August 2001 11
Service requirements for PPVPNs February, 2001
forwarding information base for a VPN. A VFI enables router
functions dedicated to serving a particular VPN. In general a VFI
terminates tunnels for interconnection with other VFIs and also
terminates access connections for accommodating CEs. The
interaction between routing and VFIs is discussed in section 5.4.
? Customer and Network Management Functions: Customer and network
management functions may use a combination of proprietary network
management system, SNMP manager, or directory service (eg, LDAP
[RFC1777] [RFC2251]).
2.9 VPN Tunnels
In a L3 PPVPN, a number of IP tunneling protocols are available,
however, in this document, three different tunneling mechanisms;
MPLS, GRE, and IPsec are considered to support VPN. In a L2 PPVPN, a
number of layer 2 tunnel types are available, the main ones being
FR, ATM, MPLS.
In a network-based PPVPN, a tunnel enables the forwarding of packets
between a specified set of CE devices via PEs accommodating them. In
a CE-based PPVPN, a tunnel exists between CE devices. Since detailed
PPVPN functions depend on the specifics on a tunnel, this section
gives an overview of tunneling protocols.
When MPLS is used for the tunneling mechanism, LSPs implement tunnels
and the multiplexing is supported by the two-layer label stacking of
the MPLS. In this case, the nested tunnels identified by the bottom
label in the stack are multiplexed into a tunnel identified by the
top label. This enables high-speed packet forwarding, because the
forwarding processing does not refer to the bottom label.
When GRE is used for the tunneling mechanism and the key field
extension is supported, the nested VPN tunnels are identified by the
key field. Note that if the key field is not present, there is no
means available to nest tunnels.
When IPsec is used for the tunneling mechanism, they are identified
by the SPI field.
Note that when the tunnel is provided by GRE or IPsec, it may pass
through another tunneling mechanism (e.g., an IPsec tunnel over an
MPLS network).
3 General Requirements
3.1 Topology
The VPN service offering should support arbitrary user defined inter-
site connectivity, ranging, for example, from hub-and-spoke, partial
mesh to full mesh topology.
An approach should support multiple VPNs per customer site.
Carugi et al Informational - Expires August 2001 12
Service requirements for PPVPNs February, 2001
To the extent possible, the PPVPN services should independent of the
access network technology.
3.2 Exchange of Data and Routing Information
A mechanism for distributing reachability information between only
those sites across a PPVPN must be provided.
A mechanism to exchange reachability information with equipment at
customer sites within a PPVPN must be provided.
A means to constrain the distribution of addressed data to only those
sites determined either by routing data and/or configuration must be
provided.
3.3 Addressing
The VPN service offering should satisfy the following addressing
requirements:
- support of customer VPN address overlapping - IP addresses have to
be unique only within a given VPN, but not across VPNs. As direct
consequence, the customer having deployed its own private numbering
scheme on every location, this IP numbering scheme must be
controlled;
- he solution should be able (easily extendable) to enable a SP
having an IPv4 or an IPv6 backbone to provide both IPv4 and IPv6 VPNs
to its customers.
- minimization of the usage of IP addresses (e.g., for mobile
users)should be pursued;
- support of NAT capabilities (NEEDS FURTHER DETAIL)
3.4 Security
CURRENT STRUCTURE OF 3.4 FOLLOWS THAT IN [VPN-CRIT].
ALIGN WITH FRAMEWORK DRAFT AND PLANNED DRAFT ON IPSEC VPNS.
THE ADOPTED STRUCTURE SHOULD BE THEN ALSO ALIGNED WITH SECURITY
SECTIONS IN CHAPTER 4 AND 5.
3.4.1 User data security
PPVPN solutions that support user data security should use standard
means to achieve confidentiality, integrity, origin authentication.
3.4.2 Routing data security
PPVPN solutions shall define means that [VPN-CRIT]:
- prevent routers of a VPN from interaction with unauthorized
entities,
- prevent routes to VPN destinations from leaking to undesired
entities,
- avoid introducing undesired routing information to taint the VPN
routing information base..
3.4.3 Access control
Carugi et al Informational - Expires August 2001 13
Service requirements for PPVPNs February, 2001
3.4.4 VPN isolation
3.4.5 Site authentication and authorization
3.5 Management
The management activity of VPN services evolves in the TMN model.
Then it will have to comply with the following requirements :
- engineer, deploy and manage the switching and transmission
resources supporting the service, from a network perspective (network
element management);
- manage the VPNs deployed over these resources (network management);
- manage the VPN service (service management) ;
- manage the VPN business, mainly provisioning administrative and
accounting information related to the VPN service customers (business
management).
The service management itself should at least include the global
activation of the TMN FCAPS functionalities.
In particular, the following aspects should be considered:
- the specification and the establishment of SLAs between the SP and
the various customers, according to the corresponding SLSes ;
- the measurement of the indicators which have been defined within
the context of the above-mentioned SLAs, on a regular basis;
- the management of the users which have been identified, so that
they may benefit from the VPN(s) deployed accordingly.
3.6 Interoperability (TEXT MAINLY DERIVED FROM [Y.1311.1])
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.
The technical solution should 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.
Service interworking among different solutions providing PPVPN
services should be also supported (in an as much as possible scalable
manner). Security and end-to-end QoS issues should be addressed.
4 Customer Requirements
4.1 VPN Membership (Intranet/Extranet)
- Multiple VPNs per customer site
Carugi et al Informational - Expires August 2001 14
Service requirements for PPVPNs February, 2001
4.2 Service Provider Independence
As customers might ask a provider for a VPN service that spans
multiple administrative domains or even beyond the provider"s
network, the service should be able to span multiple AS and SP but
still act and appear as a single, homogenous VPN to the customer. 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 AS/SP. 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. It is undesirable
that a VPN that spans multiple AS/SP can only be provisioned with a
SLA that only guarantees the least common QoS and SLA parameters.
This is of course also dependent on support agreements between the
service providers
4.3 Addressing
A variety of customer IP numbering schemes should be supported :
- private ;
- globally unique : the subscriber has deployed a globally unique IP
numbering scheme composed of public IP addresses which have been
delivered by the IANA or one of its representatives;
- no scheme : the subscriber has deployed no IP numbering scheme, and
has made no specific request either : in this case, the IP VPN
service offering should be able to address this need, whatever the
corresponding provisioning may be (i.e. private and/or public) ;
- on-demand : a dynamic IP address allocation mechanism whenever
requested by the user, and whatever the access may be, i.e. either
permanent or temporary.
4.4 Traffic Types
The IP VPN service offering should handle any kind of customer IP
traffic - namely multicast and unicast;
it might also have the ability to activate the appropriate filtering
capabilities whenever required, and whatever the filter may be, upon
request of the customer [VPN-NEEDS].
It is highly desirable to support 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.
4.5 Routing Protocol Support
There should be no restriction on the routing protocols used between
CE and PE routers, or between CE routers.
4.6 SLA/SLS
Every access link must support the specified SLA.
From an application point of view, we may at least distinguish
between:
- SLAs/SLSes for applications which are sensitive either to delay,
jitter, throughput or reliability (or a combination of the above-
Carugi et al Informational - Expires August 2001 15
Service requirements for PPVPNs February, 2001
mentioned criteria)(e.g. real-time applications, such as Voice over
IP) ;
SLAs/SLSes for applications which are not that sensitive, i.e. they
can accept an affordable degradation when being transmitted, even
from a user perspective (e.g. transactional applications).
The negotiation of appropriate QoS parameters according to the
specific application requirements is particularly important to deal
with SP network congestion periods (sensitive applications would
probably negotiate precise guarantees measured on a regular basis,
not-sensitive applications will probably rely on a per Class-of-
Service differentiation).
According to the DiffServ scheme of QoS support in IP-based networks,
a mapping function (from customer DifServ to SP"s backbone
DiffServ)should be provided at the edge of the SP network.
Support of DSCP transparency[Y.1311.1]: the SP offering the VPN
service should be able to set the IP DS field at the egress of the SP
backbone to the same value as it was on the ingress of the SP
backbone. A rationale for the support of this feature is the
following. It is stated [RFC2475] that the codepoints of the DS field
of IP packets may be changed within a DS domain by DS interior or DS
boundary nodes, but that may not be sufficient in conjunction with
the provisioning of IP VPNs, which may have specific requirements. In
particular:
- VPN customers using applications with internal CoS solutions should
have the possibility to utilize the solutions independent of the DSCP
solution supported by the SP infrastructure ;
- VPN customers supporting more DSCPs than the SP should have the
possibility to use these classes within their physical private
network sites ;
- carriers" carrier service scenarios should enable a customer SP to
offer the VPN service to his VPN customers regardless of the DSCP
solution supported by the SP identified as carriers" carrier SP.
A customer expects to have consistent QoS independent of the access
network technology used at interfaces at different sites connected to
the same PPVPN.
4.7 Management
This section describes the requirements for the customer management
in association with the provision of 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 and authenticated, authorized customer
agent.
Dynamic Bandwidth management should allow real-time response to
customer requests for changes of allocated bandwidth (control plane
should be flexible to accommodate real time changes) [Y.1311.1].
Carugi et al Informational - Expires August 2001 16
Service requirements for PPVPNs February, 2001
4.8 Security/Integrity [Y.1311.1]
Security mechanisms deployed to support the VPN service offer should
be as transparent as possible for the customer excepted maybe for
remote customers accessing the VPN through ISDN, PSTN, xDSL or
Internet for which AAA services may have to be deployed.
Users of an IP VPN should be able and allowed to deploy their own
internal security mechanisms, in addition to those deployed by the
SP, in order to secure specific applications or internal VPN traffic.
Those internal security services should ideally have to conform to SP
requirements especially when Quality of Service SLAs have been
contracted between the customer and the SP. In such a case, the
security solution deployed by the customer should not hide
information used by the SP to set up QoS features. Generally, the
constraint for the SP, in accordance with the privacy feature of the
VPN, is to ensure, as far as possible, that internal security
mechanisms which could be deployed within a VPN have a good chance to
be transparently supported by the VPN service offer.
The VPN will generally be secured according to the customer"s
requirements in order to enforce the privacy characteristic of his
VPN. This implies that the SP shall in particular ensure that :
- every equipment (e.g. router) involved in the set up of a VPN shall
be able to identify and authenticate each other so that the traffic
exchanged within the scope of a VPN can be routed. Depending on the
nature of this traffic and the nature of the equipment involved to
process it, this identification and authentication could have to be
achieved between CEs and/or between CEs and PE/P routers;
- privacy services shall be provided and integrated as a service
element by the Provider. Confidentiality and integrity services shall
apply to :
- either, all VPN traffic exchanged above the backbone between the
different sites ;
- or, some limited VPN traffic identified by a combination of
source and/or destination IP addresses and/ or protocols and/or
applications ;
- administration traffic since this latter can contain sensitive
information related to VPN configuration, users, security, accounting
;
- isolation of each VPN shall be strictly ensured and the operator
shall at least have some visibility on intrusion attempts in order to
stop those intrusions;
- in the same way, access to the various equipment deployed to
support the IP VPN service shall be strongly secured in order to
prevent unauthorized users to access the IP VPN resources. In
particular, the access to the (switching) resources which are managed
by the SP will have to be secured to prevent any kind of malicious
attack, that may well come from any kind of hacker (internet users or
else).
Carugi et al Informational - Expires August 2001 17
Service requirements for PPVPNs February, 2001
4.9 Migration Impact
VPN service customers having already deployed their own private
internetwork (whatever the technology) should not suffer from
migration considerations (whatever they are), when evolving from the
above-mentioned internetwork towards one or more Provider Provisioned
VPNs. This migration should be as smooth as possible, both from an
economical and technical perspectives [VPN-NEEDS]. Migration should
be also allowed without heavy disruption of service.
Flexible scenarios of customer migration should be allowed, from full
migration of all sites to partial migration (e.g. for a given VPN,
the migration of some sites to a PPVPN service should still ensure
service continuity with the other legacy VPN sites)[Y.1311.1].
4.10 Network Access
Every packet transmitted to or from the customer must have the usual
format without VPN-aware encapsulation.
4.10.1 Physical/Link Layer Technology
Since a VPN service offering will have to consider the connection of
sites which may belong to an enterprise (or a set of enterprises),
there should be no kind of limitation in terms of link-layer-based
access technology, such as PSTN, ISDN, xDSL, cable modem, leased
line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop,
mobile radio access, etc. (a wide range of bandwidth should be
supported, according to the specific technology in use) [Y.1311.1].
To the extent possible, the architecture for IP-layer QoS should be
independent of the access network technology.
4.10.2 Remote Access
The VPN service offering should allow both permanent and temporary
access (to one or several IP VPNs) for its users (again, with no
limitation in the type of access technology which may be used as the
IP transportation technology).
4.10.3 Sharing of the Access Network
4.10.4 Access Connectivity Multi-homing, Backdoor, Shortcut
The following types of physical connectivity scenarios must be
supported, such as multi-homed sites, backdoor links among customer
sites, etc.
Support for additional physical connectivity scenarios is desirable.
A CE device is usually accommodated by a single PE router. However,
four types of double-homing arrangements, shown in Figure 4.1, should
be supported.
Carugi et al Informational - Expires August 2001 18
Service requirements for PPVPNs February, 2001
+---------------- +---------------
+------+ +------+
+---------| PE | +---------| PE |
| |router| | |router| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|router| +---------|router| SP network
+------+ +------+
+---------------- +---------------
This type includes a CE device connected
to a PE router via two access lines.
(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 double-homing arrangements.
Carugi et al Informational - Expires August 2001 19
Service requirements for PPVPNs February, 2001
For multi-homing to single SP, load balancing capability should be
supported by the PE across the CE to PE links. For example, in case
(a), load balancing should be provided by the two PEs over the two
links connecting to the single CE. In case (c), load balancing should
be provided by the two PEs over the two links connecting to the two
CEs.
In addition, the load balancing parameters (i.e., the ratio of
traffic on the multiple load-balanced links) may be provisionable
based on customer"s requirements. The load balancing capability may
also be used to achieve a degree of redundancy.
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.11 Service Access
4.11.1 Internet Access
VPN service can be coupled with Internet access per customer site,
namely Internet access could be provided for all or part of the
customer"s sites. Various options of the Internet access service
should be supported [VPN-NEEDS]:
- traffic from or to the Internet could be processed by the
customer"s IP VPNs ;
- traffic from or to the Internet could be rejected (via appropriate
filtering capabilities) by the customer"s IP VPNs ;
access from the Internet to some of the customer Web-based servers
installed in one of his VPN sites (specific security issues need to
be addressed).
In case of combined VPN service and Internet access, support of
mechanisms that prevent from compromising the traffic exchange
between the customer private address space and the global unique
Internet address space should be supported, such as NAT.
This scenario of providing simultaneous access to the global
Internet from any site that belongs to any VPN can be achieved in a
number of ways, again, depending on the VPN mechanism used. For
example, if the PE device is composed of virtual routers, then it is
possible to access the Internet by means of a dedicated "global"
virtual router within the PE device. As previously mentioned, a
network address translation (NAT) or similar mechanism may then be
required (either at the CE or within the PE device) in order to be
able to distinguish private VPN addresses from global Internet
addresses. If the PE device does not employ virtual routers, non-VPN
(Internet) traffic may be directed by means of a default route to an
Internet Gateway. This default route is distributed to all sites
Carugi et al Informational - Expires August 2001 20
Service requirements for PPVPNs February, 2001
within a VPN to provide Internet access to all the sites. Traffic
from the Internet to particular sites within VPNs has to be handled
properly by ISPs, by distributing to the Internet routes leading to
sites within VPNs. The internal structure of the VPN would be
invisible to the Internet. A firewall function may be required to
restrict access to the VPN from the Internet [Y.1311].
4.11.2 Hosting, Application Service Provider
TBD.
4.11.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.
4.12 Hybrid VPN Scenarios
NEED COMMENTS - ALL
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, remote access, different availability of VPN solutions as
provided by different service providers.
The framework and solution approaches should include provisions for
interworking, interconnection, or reachability between different VPN
solutions in such a way that does not overly complicate provisioning,
management, scalability, or performance.
5 Service Provider Requirements
THIS INTRODUCTION TEXT REFERS TO A "NETWORK-BASED VPN" SERVICE:
APPROPRIATE ADAPTATION TO PPVPN IS NEEDED.
The following are some of the customer and provider motivations for a
network-based VPN service offering:
- Scalability - In a network-based VPN, edge-to-edge tunnels (PE-to-
PE) need to be established versus end-to-end tunnels between customer
sites, as in the CE-based VPNs. Therefore, fewer tunnels need to be
maintained and scalability problems of VC-based VPNs (e.g. ATM, FR
VPNs) are eliminated.
- Outsourcing and manageability - Network-based VPNs allow customers
who may not be able to afford the resources to manage their own sites
to outsource the VPN management to the SP. For the SP himself, on
the other hand, this presents a revenue opportunity.
- Value-added services - Customers seeking value-added services such
as multicast, web hosting, flexible SLA management and flexible
billing may benefit from network-based VPNs. Similarly, a SP can
attract more customers by providing such value-added services.
Carugi et al Informational - Expires August 2001 21
Service requirements for PPVPNs February, 2001
Security in terms of isolation and authentication - Security similar
to that obtained in VC-based VPNs can be easily provided in network-
based VPNs. Higher levels of security like edge-to-edge encryption
can be provided based on customer demand.
The following are some of the generic issues that need to be
addressed in a network-based VPN offering:
- VPN membership - The PE device needs to determine which other nodes
have members belonging to a particular VPN. In addition to this, a
PE router that advertises membership to a particular VPN should be
authorized to do so after appropriate verification. Dynamically
creating and changing VPN interconnections and managing them is
another aspect of membership that needs to be addressed in a network-
based VPN solution. A VPN identification mechanism is essential in
order to be able to identify traffic belonging to different VPNs,
which may have the same IP addresses.
- Route distribution - The distribution of reachability information
within a VPN should be done in a secure and constrained manner.
Different VPN customers may use the same non-unique IP addresses, and
these need to be distinguished on a per-VPN basis. Since a SP"s
network will be shared by multiple VPN customers, care should be
taken to preserve isolation between different customers. In addition
to this, customers wishing to access the Internet must be
distinguished from those who desire secure access to their own VPNs.
- Interworking across multiple AS"s - In an extranet scenario, a VPN
can span across multiple provider boundaries or autonomous systems.
Care should be taken that security and SLAs are maintained across
multiple autonomous system boundaries.
- QoS mechanisms and management - One of the main features of the
network-based VPN is the opportunity for the SP to provide flexible
QoS mechanisms and SLAs across its backbone, since the SP will have
complete control over the VPN traffic across its backbone. This
opportunity also presents its challenges of providing a simple and
efficient QoS mechanism, which is flexible and easily manageable.
QoS management systems based on Web-based interfaces to policy
servers and policy-based QoS control are highly desirable features of
any VPN solution. The interworking of policies across multiple
vendor equipment, as well as the accurate translation of QoS
requirements to network parameters is another major challenge.
- Security - It should be noted that network-based VPNs can provide
security by means of authentication and isolation across the SP"s
network. However, encryption in network-based VPNs does not provide
end-to-end security since the access links are not under the SP"s
control. However, if encryption across the backbone is a customer
requirement, it needs to be provided.
5.1 Scalability
Scalable routing capabilities should be supported by the service :
- the amount of routing and/or scheduling state in a P router
independent of the total number of VPNs supported by the SP and of
Carugi et al Informational - Expires August 2001 22
Service requirements for PPVPNs February, 2001
the number of VPN sites. This should be balanced against the
requirements of specific services, such as multicast,
- the amount of routing (and/or configuration) information on PE may
depend only on the VPNs whose site(s) are connected to that PE.
The content of this chapter tries to express the common understanding
among several VPN service Service Providers about scaling
requirements over the next several years(which time interval to be
considered ?) in terms of projections for number, complexity, and
rate of change (THE DIMENSIONS TAKEN INTO CONSIDERATION BELOW HAVE
BEEN DEFINED INSIDE ITU-T [Y.1311.1], THE NUMERICAL ASSUMPTIONS
REPRESENT A REVISED VERSION OF THOSE PRODUCED THERE).
The main dimensions characterizing the scalability of a Provider
Provisioned VPN service offering can be quantitatively expressed as
the number of supported VPNs to be deployed by the SP, the number of
supported terminations (permanent and temporary access)per VPN, the
number of routes to be managed per VPN.
From that perspective, the technical specification of a Provider
Provisioned VPN service offering should consider the following
numerical assumptions :
- support of a very large number, on the order of 1,000,000, of VPNs
per Service Provider network ;
- support of a wide range of number of site interfaces per VPN
(depending on size or structure of the customer organization):
ranging from a few site interfaces to 50,000 site interfaces per VPN
per customer
- support of a wide range of number of routes per VPN : ranging from
few to 200,000 routes per VPN (this number may be limited by the
choice of the routing protocol between CE and PE). Typically, the
number of routes I O(2N), where N is the number of site interfaces.
- more than one VPN per site should be possible
Numerical assumptions on VPN frequency of change (e.g.
addition/removal of sites per VPN per time unit) could be as many as
1 million per year across all SPs within the next 5 years.
High values of the frequency of configuration setup and change should
be supported, e.g. for real-time provisioning of an on-demand
videoconferencing VPN..
Numerical assumptions for complex deployment scenarios, such as
Inter-AS (SP) VPNs and carriers" carrier, should be also provided.
Which other dimensions of interest ? (bandwidth , private vs SP
network scaling)
Also need to consider scalability of management systems.
5.2 Addressing
Support should be also provided for an IP numbering scheme
outsourcing feature, which may consist for the service provider in
managing the IP numbering scheme which has been deployed by or
Carugi et al Informational - Expires August 2001 23
Service requirements for PPVPNs February, 2001
allocated to the subscriber, including the multicast addressing
scheme. Such a feature could increase the network flexibility in case
of growth and the rate of provisioning, and it could even allow cost-
effective IP numbering resource optimization.
5.3 Identifiers
A number of identifiers may be necessary for use in management,
control, and routing protocols. Requirements for at least the
following identifiers are known.
FURTHER INPUTS ON THE USAGE OF A SPECIFIC IDENTIFIER IS NECESSARY.
REQUIRES COORDINATION WITH FRAMEWORK DOCUMENT. IF IDENTIFIERS ARE
USED, THEN FUNCTIONAL CONTENT, DESCRIPTIONS REGARDING THEIR USAGE, AS
WELL AS SCOPE MUST ALSO BE PROVIDED.
A SP must be uniquely identified at least within allthe
interconnected networks of SPs. (In practice, it should be
globally unique.) This is necessary when a single VPN spans
multiple SPs.
A identifier for each PPVPN should be unique, at least within
each SP"s network.
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 logical port should have a unique identifier, at least within
each PE router containing the logical port. Here, a logicalport
represents a terminating point of an access link accommodating a user
site.
Each tunnel should have a unique identifier, at least within each
router supporting the tunnel.
5.4 Learning VPN Membership
The VPN service should support a mechanism that dynamically allows
VPN information to be learned PE and CE. This mechanism could be used
for different purposes, primarily for service scalability purposes.
5.5 Service Level Agreements and Specifications
The Service Provider offering the VPN service has to commit in some
specific service quality guarantees which will be part of the
contract signed with the customer. The agreement will constitute the
Service Level Agreement (SLA) and its corresponding technical Service
Level Specification (SLS) for that particular VPN service offer.
Carugi et al Informational - Expires August 2001 24
Service requirements for PPVPNs February, 2001
A range of (measurable) SLAs/SLSes should be provided on a per-VPN
basis to address the various VPN customer needs. A list of SLAs is
provided below (general SLA requirements for IP-based networks are
more fully described in [Y.1241], part of them being applicable for
VPNs).
NEED TO REVIEW LIST AND IDENTIFY HOW AND WHERE THE REQUIREMENTS FOR
THE IMPORTANT ITEMS WILL BE DETAILED.
Service Level Agreements, per VPN and/or per VPN site, and/or per
VPN route should include:
o Service Level Objectives comprising some or all of:
o IP Transfer Capability
o QoS parameters
o Availability
o Reliability
o Delivery confirmation
o Mobility and Portability support
o Security
o Bandwidth
o Priority
o Authentication
o Protocols supported
o Flexibility - scaling and connectivity
o Life of the SLA
o Service monitoring objectives
o QoS monitoring - comparison against objectives
o Flow tracking
o Reports as necessary
o Financial compensation objectives
o Billing option
o Penalties
o Pricing
o Early termination charges
According to the DiffServ scheme of QoS support in IP-based networks,
a mapping function (from customer DiffServ to SP"s backbone
DiffServ)should be provided at the edge of the SP network.
SLSes based on the DiffServ scheme should be provided according to
the following classification [Y.1311.1]:
- Point-to-Point SLSes (also referred as the "Pipe" model) : the
traffic parameters as well as the QoS commitment are specified on the
basis of traffic exchanged between the CE at a pair of VPN sites.
"Point-to-Point" SLSes are analogous to the SLSes typically supported
over Layer 2 technologies, such as Frame Relay and ATM. A VPN SLS
which defines compliance to the traffic contract by separate
measurement of the packets transmitted from a given VPN site towards
each remote destination VPN site is an example of "Point-to-Point"
SLS.
Carugi et al Informational - Expires August 2001 25
Service requirements for PPVPNs February, 2001
- Point-to-Cloud SLSes (also referred as the "Hose" model) : the
traffic parameters as well as the QoS commitment are specified on the
basis of traffic exchanged between a CE and a PE (as opposed to on
the basis of traffic exchanged between CEs). A VPN SLS which defines
compliance to the traffic contract by measurement of all the packets
transmitted from a given VPN site towards the SP VPN backbone on an
aggregate basis (i.e. regardless of the destination VPN site of each
packet) is an example of "Point-to-Cloud" SLS.
- Point-to-Multisite SLSes : the traffic parameters as well as the
QoS commitment are specified on the basis of traffic exchanged
between a VPN site and a subset of the other VPN sites.
5.6 QoS
Quality of Service (QoS) is expected to be an important aspect of a
PPVPN service for some customers. QoS requirements cover scenarios
involving a intranet (i.e., a VPN composed of sites from a single
customer), an extranet (i.e., a VPN composed of sites from multiple
customers), as well as shared access between a VPN and the Internet.
NOTE: THE FOLLOWING SUBSECTIONS WERE PROVIDED BY DIFFERENT SERVICE
PROVIDER AUTHORS, AND HAVE NOT BEEN ALIGNED. MAILING LIST DISCUSSION
IS SOLICITED TO FINALIZE THESE REQUIREMENTS.
5.6.1 A Service Deployment Perspective
From a service deployment perspective, we may distinguish among :
- Provider-managed CE-based VPNs : Quality of Service may be offered
based on simple classification based on prioritization, without
guarantees, or based on hard guarantees requiring more complex
mechanisms to be met.
QoS can be envisioned to be of two basic types :
1. Managed access VPN service
The managed access VPN service provides traffic prioritization or
service differentiation on the access circuit within the customer"s
own Internet/intranet traffic. Service differentiation will be
enabled only on the CE router and the customer ports of the PE
router. This service does not require implementation of DiffServ in
the core or Traffic Policing at the edge of the core network.
For the sake of simplicity, three different traffic classes are
defined: Real-Time (RT), Non-Real-Time (NRT), and Best Effort (BE).
Real-time class ensures that mission critical applications will be
given prioritized quality of service for delay sensitive
applications. NRT class refers to "better-effort" and is well suited
for non-real time applications with higher throughput requirements
than a best-effort service.
The managed access service"s customer will provide the packet
classification requirements to the service provider. It is
recommended that the SP provides several packet classification
profiles to customers. Changes can be made on the profiles depending
Carugi et al Informational - Expires August 2001 26
Service requirements for PPVPNs February, 2001
on additional customer requirements. More granular policies should be
left to the customer for implementation.
2. Full-QoS VPN service
The Full-QoS VPN service provides an end-to-end differentiated QoS to
the VPN customer. The CE router requirements for this model are the
same as the managed-access service. In the QoS VPN architecture,
DiffServ is enabled throughout the core allowing service
differentiation among all customers" traffic as opposed to the
managed access service where differentiation is within a customer"s
own traffic and only for the access link.
In this model, the VPN customer receives a service where a CIR
(Committed Information Rate) is specified for both RT and NRT
traffic. RT traffic up to CIR_RT is guaranteed low delay, delay
jitter, and packet loss rates. NRT traffic up to CIR_NRT is offered
low loss rates and moderate delay and delay jitter.
- Network-based VPN services:
In this service the Provider Edge (PE) device performs aggregation of
traffic from various CE sites. It should have the ability to support
QoS mechanisms based on the underlying network technology (MPLS/ATM
etc). Based on the customer profiles and QoS requirements, as
obtained from the policy systems, DiffServ and/or ATM QoS (if the
underlying network protocol is ATM) classification may be applied to
incoming packets at the PE. Classification could be based on one (a
combination) of a variety of factors like protocol ID, TCP or UDP
port number, byte, destination address, source address,
Differentiated Services byte etc. A variety of queueing mechanisms
like Weighted Fair Queueing, Weighted Round Robin, Class-based
Queuing, Random Early Detection (RED)etc. could be supported. In
addition, shaping and policing may be used to monitor and control
incoming and outgoing traffic at the PE. Each packet"s CoS/QoS
attributes may be marked as desired either as a DiffServ Code Points
(DSCP) or an ATM QoS class.
At the PE router, the DSCPs may be used to define service classes. As
for CE-based VPNs, three classes may be used for differentiation of
Real-Time (RT), Committed Non-Real-Time (CNRT), and Best-Effort (BE)
traffic. Once classified, packets are queued and scheduled for
transmission.
5.6.2 A Standards-Based Approach
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
Carugi et al Informational - Expires August 2001 27
Service requirements for PPVPNs February, 2001
Note that all cases involving QoS may require that the CE and/or PE
perform shaping and/or policing.
QoS may be provided on an aggregate level for all PPVPN flows
entering and leaving an interface. QoS in this case applies to
packet sent to all destinations, section 5.5 calls this the "point-
to-cloud," or "hose" SLS/SLA model. Note that the flows originating
from multiple sources may congest the interface from the network
toward the customer interface. Alternatively, QoS may be provided on
a point-to-point basis for a specific set of flows, which section 5.5
calls the "pipe" SLS/SLA model. A layer 2 VPN naturally provides this
type of QoS. Finally, as defined in section 5.5, there may be a one
point to many point SLA/SLS model. How this would map to QoS is to be
determined.
PPVPN CE should be capable of supporting integrated services
(Intserv) for certain customers in support of session types of
applications, such as switched voice or video. Intserv-capable CE
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:
- 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].
- 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 (buffer space and bandwidth) [RFC 2597].
It is believed that 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
Carugi et al Informational - Expires August 2001 28
Service requirements for PPVPNs February, 2001
PPVPN CE and PE equipment should be capable of supporting QoS across
the following types of QoS-aware packet-switched access networks:
- ATM Virtual Connections (VCs)
- Prioritized Frame Relay
- 802.1d Prioritized Ethernet
- MPLS-based access
- Multilink Multiclass PPP
5.6.3 Diffserv-Specific Requirements
In case of usage of IPSEC tunnels, appropriate mechanisms should be
supported in order to not compromise the DiffServ policies across the
SP network ([RFC2983] elaborates on this topic).
More sophisticated QoS requirements should be also supported when
needed, such as Guaranteed Bandwidth tunnels (e.g. edge-to-edge MPLS
tunnels in a Network-based VPN).
NOTE THAT FOLLOWING TEXT IS CURRENTLY DUPLICATED IN CUSTOMER
REQUIREMENTS
According to the DiffServ scheme of QoS support in IP-based networks,
a mapping function (from customer DifServ to SP"s backbone
DiffServ)should be provided at the edge of the SP network.
Support of DSCP transparency [Y.1311.1]: the SP offering the VPN
service should be able to set the IP DS field at the egress of the SP
backbone to the same value as it was on the ingress of the SP
backbone. A rationale for the support of this feature is the
following :
it is stated [RFC2745] that the codepoints of the DS field may be
changed within a DS domain by DS interior or DS boundary nodes. That
may not be sufficient in conjunction with the provisioning of IP
VPNs, which may have specific requirements :
- VPN customers using applications with internal CoS solutions should
have the possibility to utilize the solutions independent of the DSCP
solution supported by the SP" infrastructure ;
- VPN customers supporting more DSCPs than the SP should have the
possibility to use these classes within their physical private
network sites ;
- Carriers" Carrier service scenarios should enable a SP to offer the
VPN service to his VPN customers regardless of the DSCP solution
supported by the SP identified as Carriers" Carrier SP.
5.7 Resource Control
The Service provider should be able to deploy techniques to increase
efficiency in terms of network resource utilization, such as Traffic
Engineering, and this could possibly done - whenever adequate and
acceptable in terms of scalability impact - on a per-VPN basis.
5.8 Inter-AS (SP)VPNs
The scenario for VPNs spanning multiple Autonomous Systems (AS)or
Service Providers (SP) is a complex one that requires a large degree
of standardization. The scenarios where multiple AS"s are involved
Carugi et al Informational - Expires August 2001 29
Service requirements for PPVPNs February, 2001
is the most general case, and is therefore the one described here.
The scenarios of concern are the CE-based and network-based L2 and L3
VPNs defined in section 2.
In each scenario, all applicable SP requirements, such as traffic and
routing isolation, QoS, management, security, provisioning, etc. must
be preserved across PEs in adjacent AS"s.
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.8.1 Routing Protocols
If the link between AS"s or SP"s is not trusted, routing protocols
run between those AS"s or SP"s should support some form of
authentication. For example, TCP option for carrying an MD5 digest
may be used to enhance security for BGP [RFC2385]. AS"s/SP"s may
specify the AS-path by use of standardrouting protocols.
5.8.2 Management
5.8.3 Bandwidth and Qos Brokering
As a VPN should be able to span multiple AS and Service Providers,
there is a need for some kind of mechanism that requests certain
SLA/QoS parameters from the other domains and/or networks involved in
transferring traffic to various sites. This mechanism can be a manual
one, e.g. where one provider requests a specific set of QoS
parameters for traffic going to and from a specific set of sites from
another provider and receives a number of ATM VCs. The mechanism
could also be a more automated one where the network itself
dynamically requests and receives certain SLA/QoS parameters, for
instance negotiates which label to use for different traffic classes
for a set of sites 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 be for instance to dynamically request
and reserve certain QoS parameters such as bandwidth and priority,
and then to classify, mark and handle the packets as agreed upon.
Observe that as traffic might traverse multiple AS the brokering
method should also allow this.
It is not necessary to perform this kind of brokering on a per VPN
basis. Another method might be to make an agreement on a per Service
Provider basis specifying the maximum amount of bandwidth and other
QoS parameters a service provider might use as a total for all it"s
customers usage of the other providers network. Or, it might be on a
Carugi et al Informational - Expires August 2001 30
Service requirements for PPVPNs February, 2001
per VPN tunnel basis. The essential is the ability to establish and
guarantee uniform QoS across several AS/SP.
5.8.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.9 Isolation (Traffic, Processing Resources)
Routers must isolation VPNs from one another, both with respect to
forwarding and with respect to the distribution of routing
information. For example, assume that a network contains three
routers (A, B, and C) and supports three VPNs (A, B and C). Assume
also that each router dedicates one access port to each of the three
VPNs.
Each router must maintain four forwarding tables, a general table and
one table that supports each of the three VPNs. When a CE submits a
datagram the the network, the PE should forward that datagram
according to policy defined by the forwarding table that the CE
maintains for that VPN. If that forwarding table does not contain a
relevant entry, the CE should execute one of the following
procedures, depending upon its configuration:
1) discard the datagram
2) attempt to forward the datagram based upon information obtained
from the general routing table.
The PE MUST NOT forward the datagram based upon information obtain
from any other VPNs forwarding table.
Likewise, routers must isolate VPNs from one another with respect to
the distribution of routing information. In the network described
above, assume that Router A is connected directly to CE A which is a
member of VPN A. Router A may distribute routing information
concerning CE A to Routers B and C. Routers B and C may install this
information in the forwarding table that supports VPN A, but not any
of the other forwarding tables.
5.10 Tunneling Mechanism Independence and Selection
Connectivity between CE sites and SP PE to PE nodes in the backbone
should not be limited in terms of tunneling technology, such as L2TP,
IPSEC, GRE, MPLS, etc. [Y.1311.1]
A variety of tunneling technologies should be supported inside the SP
network between (a pair of) PEs, including MPLS, IPSEC, GRE, IP in
IP.
The tunneling technology used by the VPN Service Provider and its
associated mechanisms for tunnel establishment, multiplexing,
maintenance should fit the various requirements of the specific VPN
Carugi et al Informational - Expires August 2001 31
Service requirements for PPVPNs February, 2001
service offering, such as scaling, security, manageability and QoS
related ones.
To set up tunnels between PE routers, every PE router must support
static configuration for tunneling and may support a tunnel setup
protocol.
NEED FURTHER INPUTS ON TUNNEL ESTABLISHMENT AND MONITORING
REQUIREMENTS.
The 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
5.11 Backbone Technology Independence
Considering the physical and link layer technology to be used by the
SP"s backbone which will support the IP VPNs, the VPN service
offering should not depend on that. Nevertheless, the engineering
characteristics of such an IP backbone will have to be taken into
account when specifying the IP VPN service offering.
5.12 Protection, Restoration
From the access perspective, it should be possible to provide a back-
up capability whenever the primary access link from a site to one of
the IP VPN(s) fails to be operational.
This back-up capability should obviously be as dynamic as possible,
i.e. the back-up link should be dynamically established as soon as
the primary access link fails to be operational, and should become
dynamically idle as soon as the primary access link comes back up
[VPN-NEEDS].
The Service provider should be able to deploy techniques to increase
reliability and fault tolerance of the VPN service offering, such as
network protection and restoration mechanisms, and this could
possibly done - whenever adequate and acceptable in terms of
scalability impact - on a per-VPN basis. Adequate performance
indicators should be provided to qualify such capabilities.
Appropriate indicators in relation with network protection and
restoration mechanisms should be provided from the service user
perspective.
As mentioned in Section 4.10.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
Carugi et al Informational - Expires August 2001 32
Service requirements for PPVPNs February, 2001
not all) of the multi-homing 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.
5.13 PPVPN Wholesale
The architecture must support the possibility of one service provider
offering VPN service to another service provider.
This may be useful, for example, when one service provider sells
PPVPN service at wholesale to another service provider, who then
resells VPN service to his 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.
- -The Carrier"s carrier scenarios belong to 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.14 Management
FOLLOWING TEXT IS FROM Y.1311.1
Setting up the VPN and managing the deployed devices requires to take
care of three main aspects :
- connectivity : configuring, provisioning and managing the devices,
especially when topology can change
- network monitoring (particularly performance and capacity
monitoring) in order to meter resources usage and to anticipate
scalability problems
- security : authentication, authorization and overall policies
(including security risks introduced by policy inconsistency).
In order to facilitate the service management, a logical view of the
network indicating VPN topology above the backbone topology is
useful. It can be used for provisioning and verification of
connectivity, verification of configuration/privacy, fault management
and performance management.
The specification of a management information base (MIB) describing
the detailed configuration of network elements involved in the
Carugi et al Informational - Expires August 2001 33
Service requirements for PPVPNs February, 2001
provisioning of VPN services is a key requirement in network
provisioning. The general topic of MIBs for PPVN services will be
handled within the framework document.
ADDITIONAL TEXT NEEDED TO MAKE THE FOLLOWING AN EXHAUSTIVE LIST
A management system should satisfy the following requirements:
- Control, SLA measurement and accounting on a per customer basis,
- Policy for "CE-to-PE" and "PE-to-PE",
- Access to VPN parameters (e.g., security keys, location of tunnel
initiation/termination points, application-to-DSCP mappings, QoS
parameters, etc.) from a secured centralized location,
- Access to customer directory services,
- New policy and billing implemented in near real time,
- Flexibility in terms of service scenarios to be managed, such as
customer site connectivity, topologies, deployment scenarios, types
of customer IP traffic (v4/v6, unicast/mcast,...).
FOLLOWING TEXT FOR ALL 5.14.1, 5.14.2 SECTIONS IS FROM ITU Y.1311.1
Both the SP and its customers should be able to manage the
capabilities and characteristics of their VPN services.
Automated operations and interoperability with standard management
platforms should be pursued.
5.14.1 Configuration Management
Following the VPN growth, configuration management for VPNs,according
to service templates defined by the provider must be supported. VPN
configuration management is needed for basic components such as PE
and CE, for example to provision VPN tunnels and access
network/links.
The management system could centralize such a process to guarantee
coherence of parameters and accelerate deployment by automating
configuration. As VPN configuration and topology highly depends on
the customer"s organization, provisioning templates have to apply to
the customer"s specific requirements (remote accesses, security
policy, QoS). The management system could rely on centralized
information to get all needed parameters for optimal adaptation of
templates to specific needs.
Such a system may increase the network reactivity in case of failure
or policy violation. It can reduce provisioning delay in case of
current VPN configuration requested by the customer (add, modify,
delete), which can be a very heavy task in terms of routing tables
update.
In a multi-domain environment, the end-to-end QoS depends on the QoS
provided by each domain. In case of a VPN spanning accross two
domains, QoS provisioning may reach its limit and such a problem
seems difficult to solve.
Carugi et al Informational - Expires August 2001 34
Service requirements for PPVPNs February, 2001
Conformance between configured results and customer specific
requirements should be verified. This topic is covered in sections
5.14.1.3 and 5.14.1.4.
5.14.1.1 Configuration Management for Network-Based VPNs
Concrete requirements on configuration management for Network-based
VPN are described as follows.
o The configuration of PE routers must be supported. Their management
information includes IP routing information and access control policy
information for intranet and extranet membership.
o Systematic alignment of related identifiers and mapping of these
identifiers according to configuration are important when configuring
PPVPNs. Identifiers for SPs, PPVPNs, PEs, CEs, VPN tunnels and
identifiers for logical ports as mentioned in Section 5.3 must be
configurable to realize desired L2 connectivity and/or L3
reachability of the NBVPN.
NOTE: ALIGNMENT WITH SEC. 5.3 IS NEEDED
o Tunnel information must be configured. It includes the identifiers
of tunnels, identifiers of logical links, tunnel states, and QoS/SLA
information for QoS/SLA service.
o Routing protocols running between PE routers and CE devices must be
configured per VPN. For multicast service, multicast routing
protocols must also be supported.
o Routing protocols running between PE routers must be configured.
For multicast service, multicast routing protocols must also be
supported.
o The configuration of network-based PPVPN must be coordinated with
the configuration of the underlying infrastructure, including Layer 1
and 2 networks interconnecting components of PPVPN.
5.14.1.2 Configuration management for CE-based VPN
NOTE: TO BE WRITTEN
5.14.1.2 Verification of L2 Connectivity and L3 Reachability
It is desirable that a capability to verify the L2 connectivity or L3
reachability between CE at user sites within a VPN is provided. If a
logical view of a VPN is provided and the result of this verification
is shown in this view, the operator can understand the result easily.
NOTE:ABOVE TEXT REQUIRES MORE REVIEW/ POSSIBLE REVISION.
5.14.1.3 Verification of configuration and privacy
It is desirable that a capability to verify the configuration and
privacy of a VPN is provided. Privacy here means that the VPN cannot
be accessed from outside of this VPN. If a logical view of a VPN is
Carugi et al Informational - Expires August 2001 35
Service requirements for PPVPNs February, 2001
provided and the result of this verification is shown in this view,
the operator can understand the result easily.
NOTE:ABOVE TEXT REQUIRES MORE REVIEW/ POSSIBLE REVISION.
5.14.2 Service monitoring
Network monitoring in the VPN perspective includes the classical
items such as fault management, service-level management and
accounting.
5.14.2.1 Fault management
As VPNs rely on a common network infrastructure, the network
management system should provide means to inform the provider on the
consequences of a device failure for the VPNs it supported. The NM
should provide a logical view of the network indicating VPN topology
above the backbone topology. It should provide pointers to the
related configuration and customer"s requirement information so as to
ease fault isolation and take corrective action as impact on traffic
engineering and security considerations may be important.
To summarize, fault management includes :
- customers information of failures,
- faults detection (incidents reports, alarms, failures
visualization, SLA violation),
- faults localization (analysis of alarms reports, diagnosis),
- incidents recording, logs,(creation and following of the trouble
ticket),
- corrective actions (traffic, routing, resources ...).
It is desirable to detect faults cause by configuration errors,
because these may cause VPN service to fail, or not meet other
requirements (e.g., traffic isolation). Detection of such errors is
inherently difficult because the problem involves more than one node
and may reach across a global perspective. On approach could be a
protocol that systematically checks that all constraints and
consistency checks hold between tunnel configuration parameters at
the various end points.
5.14.2.2 Performance management
The performance management system should be able to monitor network
behaviour in order to evaluate performance metrics that form part of
the service-level agreements. Multiple different VPN services are
subscribed by the customers and the system should be able to deploy
specific measurement techniques depending on the activated service
components (security, multicast, remote access). These techniques may
be either intrusive or non-intrusive depending on the parameters or
service being considered.
QoS deployment and SLA monitoring may be coupled by monitoring
policies that :
- describe QoS mechanisms and the associated metrics that should be
activated
Carugi et al Informational - Expires August 2001 36
Service requirements for PPVPNs February, 2001
- control monitoring resources such as probes and remote agents
Remote agents may be a key to the network monitoring as it allows the
collection of statistics directly at the network access points used
by customers and mobile users. A logical view of the network
indicating the VPN topology helps operators to understand the result
of the performance management activities.
To summarize, performance management includes :
- real-time performance measurements (indicators and thresholds
initialization and modification, data collection),
- real-time monitoring (resources utilization), VPN status (up/down),
- analysis (bandwidth, response time, availability, packet loss),
- statistics and trends based on collected metrics.
Additionally, the performance management system should have a
"Dynamic Bandwidth management" capability :
- Dynamic Bandwidth management should allow real-time response to
customer requests for changes of allocated bandwidth (control plane
should be flexible to accommodate real time changes) (*)
- Performances (e.g. bandwidth allocation) should be traceable
(*): Dynamic bandwidth allocation would normally occur within the
ranges and bounds specified in the Service Level Agreement (SLA),
possibly using internal SP mechanisms to check appropriate
allocation.
5.14.2.3 Accounting
Being able to associate service profiles to customers and to the
resources providing these services may facilitate accounting, which
can be a key feature of subscribed services. The accounting system
has to be able to sort among the huge amount of usage information and
correlate this information to performance and fault management
information to produce billing according to the real provided
service. It should be noted that accounting requirements may conflict
with security requirements.
To summarize, accounting process includes :
- measurements of resources utilization,
- production of accounting information,
- measurement storage (files creation and administration),
- quotas control per customer (current consumption update,
consumption authorizations checking).
5.14.2.4 Security management features
The security management system of a VPN solution must include
management features to guarantee the security of network connections,
the privacy and integrity of data, as described in section 5.16.
5.14.2.5 Access Control
TEXT OF THIS CHAPTER SHOULD BE REVISED TO JUST INDICATE SUPPORT OF
SECURITY MANAGEMENT FEATURES FOR ACCESS CONTROL (AUTHENTICATION, DATA
PRIVACY). TEXT CURRENTLY PROVIDED BELOW IS A DESCRIPTION OF SECURITY
Carugi et al Informational - Expires August 2001 37
Service requirements for PPVPNs February, 2001
FEATURES, SO IT HAS A MORE APPROPRIATE LOCATION IN SECURITY SECTION
5.16 (REDUNDANCY WITH THIS SECTION HAS ALSO TO BE CHECKED).
Access control dictates the amount of freedom a VPN user has, and
controls the access of other users to applications and different
parts of the network.
A VPN without access control only protects the security of the
transported data but not the network. Access control capabilities
protect the entire network to ensure that VPN users have complete
access to the applications, but only to these resources.
In case of negotiated customer bandwidth, the access control at
network level should ensure that each customer doesn"t violate his
contract.
5.14.2.5.1 Authentication
Authentication is the process of verifying that the sender is
actually who he says he is.
Support for strong authentication schemes is particularly important
to ensure the privacy 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 (
e.g. PE fake to enter a specific or a set of VPNs) in the presence of
auto-discovery mechanisms.
Nomadic access implying dynamic evolution of PEs serving a specific
VPN is another situation which requires such authentication schemes
in the presence of autodiscovery mechanisms. A variety of
authentication methods are available to meet the needs of particular
VPN deployments, including username/password authentication, RADIUS
or TACACS servers, LDAP directory servers, X.509 digital
certificates, smart cards, ...
Scalability is critical when the number of nomadic/mobile clients is
increasing. The authentication scheme implemented for such
deployments must be both manageable and easily deployed for large
numbers of users and VPN access points.
5.14.2.5.2 Data privacy
A VPN solution should protect the privacy of the data being
transmitted. Here data means both user and control information.
Data privacy could be provided by encryption or by other mechanisms,
e.g. data separation.
It may support multiple encryption algorithms and encryption schemes,
including DES, 3DES, and the IPSec standards. Encryption, decryption,
and key management could be included in profiles that may be inforced
by a policy-based management system. It should be possible to
activate encryption on specific services.
5.14.2.6 SLA and QoS management features
The management system should support :
- specification and the establishment of SLAs between the SP and the
various customers, according to the corresponding SLSes ;
Carugi et al Informational - Expires August 2001 38
Service requirements for PPVPNs February, 2001
measurement of the indicators which have been defined within the
context of the above-mentioned SLAs, on a regular basis.
FOLLOWING TEXT (SECTION 5.14.3) MAY BE MORE APPROPRIATE FOR FRAMEWORK
AS A POTENTIAL SOLUTION - - NEED COMMENTS AND INPUT - - NARAIN, IF YOU
HAVE TIME LOOK TO SEE IF LIST IN 5.14.3 IS CORRECT, SHOULD BE
AUGMENTED.
5.14.3 VPN management solutions
The following options are available for deploying management systems
for the VPN offering:
1. Use a call center model for customer control,
2. Deploy proprietary or custom-made management solutions,
3. Deploy a standards-based, policy-based VPN management solution
The third option is more scaleable and interoperable and are
beneficial to both the customer and the provider. The following
chapter describes this option.
5.14.3.1 Policy-based management model
This model contains four functional areas: configuration; network
element; policy engine; and billing. The configuration and billing
functional areas provide the customer with a "window" into the
provider"s network. Customers can see the level of service that they
have and alter it accordingly. The other functional areas view the
customer configurations as parameters which must be satisfied.
This is the first option where the customer can view and configure
the network in near real time. The network is configured by either
defining policy in a customer owned directory service or by
configuring the service by using a web browser. The web browser sends
information directly to the policy engine, which is the service
control point of the system. The policy engine can also access policy
information through LDAP connections to the customer directory
service.
Policy-based management provides the ability to specify rules to
govern the behavior of a service. The function of the policy engine
involves retrieving and interpreting policy, detecting conflicts,
sending the policy to the Policy Enforcement Points (PEP), being
aware of network health, SLA requirements, and tracking how customers
are currently using the network. The policy engine communicates
policy to the PEP by using COPS (Common Open Policy System) and
information is communicated back using traditional management
protocols (e.g., SNMP). Policy is described by using the Policy Core
Schema.
Carugi et al Informational - Expires August 2001 39
Service requirements for PPVPNs February, 2001
The billing system receives notifications of the changes made by the
customer through the policy engine. The customer may view current
service parameters at any time by coupling the billing system with
the HTTP server.
Deploying a policy-based system satisfies the following customer
management requirements:
- Customer control via a web-based service or a directory enabled
service,
- Flexible administrational policy to any number of elements,
- Fully automated to satisfy non-real time requests based on the
current network condition.
5.15 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.
5.16 Isolation, Security, Authentication and Identification
SECTION 5.16 COMES FROM [Y.1311.1]
The following security functions (described hereafter) should be
considered in a PPVPN service offering:
- isolation ;
- user identification ;
- user authentication ;
- security of the flow ;
- peer identification ;
- peer authentication ;
- site protection.
5.16.1 VPN isolation
From the SP perspective and at a high level of description, the VPN
isolation function consists in ensuring that all traffic exchanged
within the scope of a VPN remains unknown and protected from other
users of the backbone and insensitive with regard to traffic
transported over the supporting backbone.
From this perspective the SP shall ensure, when deploying the
service, that it conforms to the following characteristics :
- only a set of pre-defined users can access the VPN,
- QoS SLA shall be guaranteed whatever the state of the traffic
experienced in the supporting IP backbone and especially when this
traffic is generated by other customers within or outside the scope
of the VPN service,
- IP connectivity shall be deployed in such a way that only recorded
VPN sites and registered remote users can exchange traffic within the
Carugi et al Informational - Expires August 2001 40
Service requirements for PPVPNs February, 2001
VPN. This may lead peer equipment to identify/authenticate each other
at different level of the VPN service,
- traffic exchanged might be secured thanks to encryption and/or
authentication functions,
- VPN management functions shall not impact other VPN or IP services.
This isolation function is achieved by application of a combination
of functions related to architecture, quality of service, security
and administration functional domains. This set of functions,
correctly deployed, constitutes a generic function called "VPN
isolation". This function is nevertheless classified within the
security domain due to the strong implication of security features in
the realization of such a global isolation function.
5.16.2 VPN user identification
Among VPN users can be found travelling people who are not
permanently attached to one of the sites of the VPN. In order to
control the access of those users to the VPN it is necessary to
identify them. This identification shall apply within the various
deployment context which have been identified (intranet, extranet,
sub-vpn), keeping in mind that some of these users can have an access
to several distinct VPNs. This identification function can be used to
automate or trigger all technical actions which are necessary to
establish the communication with the VPN he wants to connect to. Two
main identification contexts have to be considered :
- identification in case of "mobility", whatever it is an intra-site
or inter-site mobility,
- identification when the user tries to reach his IP VPN from a
public or private access point through a NAS/BAS server or even from
a network having an Internet access to which he has a temporary
access.
This function can be implemented by the VPN SP in totality or
partially. Roaming capabilities could probably have to be set-up
between the Provider and the customer who might well decide to
perform the VPN user identification in case he would not accept to
outsource the identification/authentication service. In fact this
identification will be used by the access SP who needs to identify
the user to provide the IP connectivity and by the VPN user
identification service in order to accept the VPN connection. The two
mechanisms can be linked.
In this case the access Provider and the VPN SP resources have to
cooperate and an agreement has to be reached on common identification
specification.
All information necessary to identify the users will have to be
stored and should ideally be maintained by the customer. This
information should be made available to the access Provider for
controlling the IP access.
Carugi et al Informational - Expires August 2001 41
Service requirements for PPVPNs February, 2001
5.16.3 VPN user authentication
The scope of this authentication function is the same than above and
concerns users in a remote access situation. This authentication
function will consist in ensuring, with a good level of confidence,
that the declared user is the one is claiming to be.
Various authentication protocols might be used for that purpose
depending on the level of security wished by the customer but at
least PAP, CHAP and challenged mechanisms should be supported since
they are currently widely used in a large range of equipment and
services.
This authentication function may be executed completely or partially
by the VPN SP. In the latter case the authentication phase can be
relayed to the customer access point according to the terms of the
contract.
5.16.4 Securing the flow
Within the present context which consist in deploying a VPN over a
public IP backbone (which is part of the Internet), the sole routing
functions are not sufficient to secure the flows of a given customer.
As a matter of fact, even if the flows are correctly routed between
the sites (including remote users), the corresponding traffic might
be intercepted and consequently read or altered. Securing the flows
should be enforced at the network layer to ensure the two main
characteristics :
- privacy of the traffic, so that only authorized equipment decrypt
it,
- integrity, to protect recipients from alteration which could have
been introduced during the transport.
These two functions shall apply to what is called here the "data
traffic" of the customer which includes the traffic exchanged between
sites, between remote users and sites and even between remote users.
But it shall also apply to "control traffic", which is not
necessarily perceived by the customer but nevertheless essential to
maintain his VPN.
Even if it is strongly recommended to deploy those functions in an
operational context, these functions shall not be considered as
mandatory and should be activated only if requested by the customer.
In the same kind of idea, those functions should be as flexible as
possible so that they can be deployed independently from each other
and applied to some part of the traffic (security level may differ
depending the traffic which is considered, performance considerations
may also lead to secure a sub-set of the traffic).
5.16.5 Peer identification
Traffic exchanged within the scope of VPN may involve several
categories of equipment that need to cooperate together to provide
the service. These network elements can be CE, firewalls, backbone
routers, servers, management stations, etc.
Carugi et al Informational - Expires August 2001 42
Service requirements for PPVPNs February, 2001
Each time two network elements need to cooperate, it is necessary for
the peer to proceed to an identification (enforced by an
authentication if needed, see below) before accepting to process the
received traffic or to provide the requested service. This
identification can be used as a trigger to adapt the way the service
will be provided but in most cases to control the access to the
network resources.
This peer identification function is intended here to apply only to
network elements participating in the VPN setup. Are excluded here
all identification needs related to users" applications.
Examples of such peer identification could apply to :
- traffic between a CE and a SP access point (P/PE access point),
- traffic between CEs belonging to the same VPN,
- routers dealing with route announcement (these routers could be a
CE and P/PE router or two CEs exchanging routing information),
- policy server and a network element,
- management station and an SNMP agent,
etc.
This identification function shall not be considered as an atomic
function since it is rather distributed and probably implemented
differently depending on network elements which are considered. But
globally, the VPN service shall provide a peer identification
function in defining where it is necessary, how it shall be
implemented, how secured it shall be and the way to deploy and
maintain identification information necessary to operate the service.
5.16.6 Peer authentication
This function is the prolongation, in security terms, of the above
function. It aims at authenticating the peer following the same
philosophy adopted for user identification and authentication.
5.16.7 Site protection
A site might be involved in various ways within the scope of a VPN.
It can be part of a VPN deployed to support an Intranet (in that case
he is inter-connected with sites belonging to the same company), part
of an IP VPN deployed between different companies to support an
Extranet, or both.
Within this context, a site might be subject to various attacks
coming from different sources. These potential sources are :
- users connected to the supporting public IP backbone, since by
definition a IP VPN is built over a public and shared IP
infrastructure,
- users from the Internet, if the backbone offers an Internet access,
- users from remote sites belonging to the VPN the site is part of.
Risks that a site may encounter are the following:
Carugi et al Informational - Expires August 2001 43
Service requirements for PPVPNs February, 2001
- service denial (when a hacker acts in such a way that a service
cannot be used. Mail spamming and access line overloading for
instance) ;
- viruses ;
- intrusions.
In order to prevent those risks the VPN SP shall deploy functions
that control access to the site, thanks to the deployment of
filtering functions provided by firewall for instance but also in
monitoring, alerting and eventually logging all suspicious activities
in order to detect all possible attacks.
5.17 Provisioning Routing [Y.1311.1]
Filtering of VPN routing information in the PE-to-PE and CE-to-PE
configurations should be supported.
A variety of routing protocols should be supported at the edge and
the core level of the Service Provider network :
- there should be no restriction on the routing protocols used
between CE and PE routers ;
- the choice of SP"s IGP must not depend on the routing protocol(s)
used between PE and CE routers. Furthermore, that choice should be
flexible, not limited to a single routing protocol.
5.18 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.
5.19 Provisioning Security Services
Deployment scenarios with application of security should be provided
(managed CE-based VPNs, L2 VPNs, L3 VPNs)
5.20 Provisioning VPN Parameters
Need to have a means to dynamically provision resources associated
with implementations of VPN services (e.g., virtual routing
instances, table space, etc.).
The dynamic nature of the VPN resource assignment is crucial to cope
with the frequent changes from the customer side (e.g., users joining
and leaving the VPN), and achieve scalability. The PEs should be able
to dynamically assign the VPN resources. This capability is
especially important for dial and wireless VPN services.
5.21 Provisioning Value-Added Service Access
A VPN service is from a business point of view quite simple, only
providing access between different sites over a common backbone.
Other market drivers for the SP business is various kinds of
services, and when these are provided through the VPN service itself,
we might regard them as value added services. Examples of these kinds
of services is for instance Internet access, firewall services, virus
screening, IP telephony and IP centrex, application hosting, backup,
etc. It is out of this documents scope to define if and how these
Carugi et al Informational - Expires August 2001 44
Service requirements for PPVPNs February, 2001
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.
5.21.1 IP Networking 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.
The VPN service offering should allow the outsourcing of IP services.
The management system could rely on centralized information to get
all needed parameters for optimal adaptation of IP services to
specific needs. This could also allow cost-effective optimization by
offering services at a large range of customers.
5.21.2 Internet access
Network-based firewall services must be carrier grade. For redundancy
and failure recovery, means for firewall fall-over should be
provided. Network-based firewall services that may be provided
include virus scanning, traffic-rate limiting against malicious
attacks, etc.
Network-based firewalls must be supported on a per-VPN basis
(although multiple VPNs may be grouped into the same firewall).
Network-based firewalls should be provided at the major access
point(s) for the PPVPN. Network-based firewall services can be
embedded in the PE equipment, or can be standalone equipment.
5.22 Provisioning Hybrid VPN Services
Service interworking between the identified solutions for PPVPN
services and other solutions providing VPN services (e.g. VC-based
VPNs) should be also supported. Security and end-to-end QoS issues
should be addressed.
5.23 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
6 Security Considerations
TBD
Carugi et al Informational - Expires August 2001 45
Service requirements for PPVPNs February, 2001
7 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 framewbork document [RFC 2764], Tom Worster, Ron
Bonica, and Sanjai Narain.
8 References
[RFC1777] Yeong, W. et al., "Lightweight Directory Access
Protocol," RFC 1777, March 1995.
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC-2251] Wahl, M. et al., "Lightweight Directory Access Protocol
(v3)," RFC 2251, December 1997.
[RFC-2661] Townsley, W. et al., "Layer Two Tunneling Protocol
"L2TP"," RFC 2661, August 1999.
[RFC-2547] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs," RFC 2547,March
1999.
[2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work in
progress.
[RFC-2764] 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 Draft Recommendation,
November 2000
(http://nbvpn.francetelecom.com/ituRelated.html)
[Y.1311] Jamoussi, B. (editor), " Network based IP VPN Service -
Generic Framework and Service Requirements ", Y.1311 ITU-
T Draft Recommendation, November 2000
(http://nbvpn.francetelecom.com/ituRelated.html)
Carugi et al Informational - Expires August 2001 46
Service requirements for PPVPNs February, 2001
[L2 VPN] K. Kompella et al, "MPLS-based Layer 2 VPNs," work in
progress
[L2 MPLS] L. Martini et al, "Transport of Layer 2 Frames Over
MPLS," work in progress.
[RFC 2205]
[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
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC2983, October 2000
NOTE: LIST OF REFERENCES MAY NOT BE COMPLETE, AND NOT ALL REFERENCES
LISTED ARE CURRENTLY CITED.
9 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 52Email : marco.carugi@francetelecom.fr
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
Luyuanfan@att.com
Fredrik Johansson
Telia Research
5E-123 86 Farsta, Sweden
frederik.xz.johansson@trab.se
Ananth Nagarajan
Sprint
Carugi et al Informational - Expires August 2001 47
Service requirements for PPVPNs February, 2001
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
Zephion Networks
rwilder@bbo.com
Full copyright statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Carugi et al Informational - Expires August 2001 48
| PAFTECH AB 2003-2026 | 2026-04-21 01:24:08 |