[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [iesg-secretary #5032] Please submit draft-ietf-ppvpn-generic-reqts-02.txt to IESG for r
Your request #5032 was resolved by jhargest:
We received your request, and this version is currently in the
system.
>>>>>>>>>>>>>>>>>> Original Message >>>>>>>>>>>>>>>>>>
>From: "Marco Carugi" <marco.carugi@nortelnetworks.com>
>To: "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>, sob@harvard.edu
>Subject: Please submit draft-ietf-ppvpn-generic-reqts-02.txt to IESG for r
------_=_NextPart_000_01C2BCBC.47FBD95A
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C2BCBC.47FBD95A"
------_=_NextPart_001_01C2BCBC.47FBD95A
Content-Type: text/plain;
charset="iso-8859-1"
Scott, Bert,
I would like to request submission of the attached draft (PPVPN
Generic Requirements) to the IESG for review before approval as an
Informational RFC.
The WG last call for draft-ietf-ppvpn-generic-reqts-01.txt was completed on
January 10
and the only change in 02 version (the attached one) is the addition of
Table of Contents. The 02 version is not yet available in the I-D
repository (it has been submitted today).
Thanks, Marco Carugi (PPVPN WG co-chair)
------_=_NextPart_001_01C2BCBC.47FBD95A
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Please submit draft-ietf-ppvpn-generic-reqts-02.txt to IESG for =
review (to Informational RFC)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Scott, Bert, </FONT>
<BR><FONT SIZE=3D2>I would like to request submission of the attached =
draft (PPVPN </FONT>
<BR><FONT SIZE=3D2>Generic Requirements) to the IESG for review before =
approval as an </FONT>
<BR><FONT SIZE=3D2>Informational RFC. </FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>The WG last call for =
draft-ietf-ppvpn-generic-reqts-01.txt was completed on January 10 =
</FONT>
<BR><FONT SIZE=3D2>and the only change in 02 version (the attached one) =
is the addition of Table of Contents. The 02 version is not yet =
available in the I-D repository (it has been submitted =
today).</FONT></P>
<P><FONT SIZE=3D2>Thanks, Marco Carugi (PPVPN WG co-chair)</FONT>
</P>
<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"></FONT>
</BODY>
</HTML>
------_=_NextPart_001_01C2BCBC.47FBD95A--
------_=_NextPart_000_01C2BCBC.47FBD95A
Content-Type: text/plain;
name="draft-ietf-ppvpn-generic-reqts-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-ppvpn-generic-reqts-02.txt"
Content-Transfer-Encoding: quoted-printable
Internet Draft Ananth Nagarajan
Expiration Date: July 2003 Sprint
Category: Informational (Editor)
January 2003
Generic Requirements for Provider Provisioned VPN
<draft-ietf-ppvpn-generic-reqts-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC-2026].
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that =
othergroups
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.
Abstract
This document describes generic requirements for Provider Provisioned
Virtual Private Networks (PPVPN). The requirements are categorized into
service requirements, provider requirements and engineering
requirements. These requirements are not specific to any particular
type of PPVPN technology, but rather apply to all PPVPN technologies.
All PPVPN technologies are expected to meet the umbrella set of
requirements described in this document.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
[Page =
1]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
this document are to be interpreted as described in [RFC-2119].
Table of Contents
1. Introduction .................................... 3
1.1. Problem Statement ............................... 3
1.2. Outline of this document ........................ 4
2. Contributing Authors ............................ 5
3. Definitions and Taxonomy ........................ 6
4. Service Requirements ............................ 7
4.1. Availability .................................... 7
4.2. Stability ....................................... 7
4.3. Traffic types ................................... 7
4.4. Data Isolation .................................. 8
4.5. Security ........................................ 8
4.5.1. User data security .............................. 9
4.5.2. Access Control .................................. 9
4.5.3. Site authentication and authorization ........... 9
4.5.4. Inter domain security ........................... 9
4.6. Topology ........................................ 10
4.7. Addressing ...................................... 10
4.8. Quality of Service .............................. 10
4.9. Service Level Agreement and Service Level
Specification Monitoring and Reporting .......... 11
4.10. Network Resource Partitioning and Sharing
between VPNs .................................... 12
5. Provider requirements ........................... 13
5.1. Scalability ..................................... 13
5.1.1. Service Provider Capacity Sizing Projections .... 13
5.1.2. VPN Scalability aspects ......................... 14
5.1.3. Solution-Specific Metrics ....................... 16
5.2. Management ...................................... 16
5.2.1. Customer Management of a VPN .................... 17
6. Engineering requirements ........................ 17
6.1. Forwarding plane requirements ................... 17
6.2. Control plane requirements ...................... 18
6.3. Control Plane Containment ....................... 18
6.4. Requirements related to commonality of PPVPN
mechanisms with each other and with generic=20
Internet mechanisms ............................. 19
6.5. Interoperability ................................ 19
7. Security Considerations ......................... 20
8. References ...................................... 20
8.1. Normative References ............................ 20
8.2. Informative References .......................... 20
9. Acknowledgements ................................ 21
10. Editor's Address ................................ 21
11. Full Copyright Statement ........................ 22
[Page =
2]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
1. Introduction
This document is an output of the design team formed to develop
requirements for PPVPNs in the PPVPN working group. As such this
work fits within the scope of the PPVPN working group. This
document discusses generic PPVPN requirements categorized as
service, provider and engineering requirements. These are
independent of any particular type of PPVPN technology. In other
words, all PPVPN technologies are expected to meet the umbrella set
of requirements described in this document. Specific requirements
related to Layer 3 PPVPNs are described in [L3REQTS]. Similarly,
requirements that are specific to layer 2 PPVPNs are described in
[L2REQTS].
1.1. Problem Statement
Corporations and other organizations have become increasingly
dependent on their networks for tele and data communication. The =
data
communication networks were originally built as Local Area Networks
(LAN). Over time the possibility to interconnect the networks on
different sites has become more and more important. The
connectivity for corporate networks has been supplied by service
providers, mainly as Frame Relay (FR) or Asynchronous Transfer Mode
(ATM) connections, and more recently as Ethernet and IP-based
tunnels. This type of network, interconnecting a number of sites
over a shared network infrastructure is called Virtual Private
Network (VPN). If the sites belong to the same organization, the =
VPN
is called an Intranet. If the sites belong to different
organizations that share a common interest, the VPN is called an
Extranet.
Customers are looking for service providers to deliver data and
telecom connectivity over one or more shared networks, with service
level assurances in the form of security, QoS and other parameters.
In order to provide isolation between the traffic belonging to
different customers, mechanisms such as Layer 2 connections or Layer
2/3 tunnels are necessary. When the shared infrastructure is an IP
network, the tunneling technologies that are typically used are
IPsec, MPLS, L2TP, GRE, IP-in-IP etc.
Traditional Internet VPNs have been based on IPsec to provide
security over the Internet. Service providers are now beginning to
deploy enhanced VPN services that provide features such as service
differentiation, traffic management, Layer 2 and Layer 3
connectivity, etc. in addition to security. Newer tunneling
mechanisms have certain features that allow the service providers =
to
[Page =
3]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
provide these enhanced VPN services.
The VPN solutions we define now must be able to accommodate the
traditional types of VPNs as well as the enhanced services now being
deployed. They need to be able to run in a single service =
provider's
network, as well as between a set of service providers and across =
the
Internet. In doing so the VPNs should not be allowed to violate =
basic
Internet design principles or overload the Internet core routers or
accelarate the growths of the Internet routing tables. =
Specifically,
Internet core routers shall not be required to maintain VPN-related
information, regardless of whether the Internet routing protocols =
are
used to distribute this information or not. In order to achieve =
this,
the mechanisms used to develop various PPVPN solutions shall be as
common as possible with generic Internet infrastructure mechanisms
like discovery, signaling, routing and management. At the same =
time,
existing Internet infrastructure mechanisms shall not be overloaded.
Another generic requirement from a standardization perspective is to
limit the number of different solution approaches to provide a
specific type of VPN to as small a number as possible.
1.2. Outline of this document
This document describes generic requirements for Provider =
Provisioned
Virtual Private Networks (PPVPN). The document contains several
sections, with each set representing a significant aspect of PPVPN
requirements. Section 2 lists authors who contributed to this
document. Section 3 defines terminology and presents a taxonomy of
PPVPN technologies. The taxonomy contains two broad classes,
representing Layer 2 and Layer 3 VPNs. Each top level VPN class
contains subordinate classes. For example, the Layer 3 VPN class
contains a subordinate class of PE-based Layer 3 VPNs. Sections 4,
5, 6 describe generic PPVPN requirements.
The requirements are broadly classified under the following
categories:
1) Service requirements - Service attributes that the customer can
observe or measure. For example, does the service forward frames or
route datagrams? What security guarantees does the service provide?
Availability and stability are key requirements in this category.
2) Provider requirements - Characteristics that Service Providers =
use
to determine the cost-effectiveness of a PPVPN service. Scaling and
management are examples of Provider requirements.
[Page =
4]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
3) Engineering requirements - Implementation characteristics that
make service and provider requirements achievable. These can be
further classified as:
3a) Forwarding plane requirements - e.g., requirements related to
router forwarding behavior.
3b) Control plane requirements - e.g., requirements related to
reachability and distribution of reachability information.
3c) Requirements related to the commonality of PPVPN mechanisms with
each other and with generic Internet mechanisms.
2. Contributing Authors
This document was the combined effort of several individuals that
were part of the Service Provider focus group whose intentions were
to present Service Provider view on the general requirements for
PPVPN. A significant set of requirements were directly taken from
previous work by the PPVPN WG to develop requirements for Layer 3
PPVPN [L3REQTS]. The existing work in the L2 requirements area has
also influenced the contents of this document [L2REQTS].
Besides the editor, the following are the authors that contributed =
to
this document:
Loa Andersson
Ron Bonica
Dave McDysan
Junichi Sumimoto
Muneyoshi Suzuki
David Meyer
Marco Carugi
Yetik Serbest
Luyuan Fang
Javier Achirica
[Page =
5]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
3. Definitions and Taxonomy
The terminology used in this document is defined in [TERMINOLOGY]. =
In
addition the following terminology is used:
Site: a geographical location with one or more users or one or more
servers or a combination of servers and users.
User: the end user equipment (hosts), e.g., a workstation.
PPVPN
________________|__________________
| |
Layer 2 (L2) Layer 3 (L3)
______|_____ ______|________
| | | |
PE-based CE-based PE-based CE-based
|
|___________
| |
P2P P2MP
The figure above presents a taxonomy of PPVPN technologies. =
Although
the above figure shows the classification for PE-based Layer 2 =
VPNs,
it should be noted that CE-based Layer 2 PPVPNs may also be further
classified as point-to-point (P2P) or point-to-multipoint (P2MP).
However, there are not many solutions in the CE-based Layer 2 PPVPN
space being proposed. It is also the intention of the working group
to have a limited number of solutions, and this goal must be kept in
mind when proposing solutions that meet the requirements specified =
in
this document. Definitions for CE-based and PE-based PPVPNs can be
obtained from [L3FRAMEWORK]. Layer 2 specific definitions can be
obtained from [L2FRAMEWORK].
[Page =
6]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
4. Service requirements
These are the requirements that a customer can observe or measure, =
in
order to verify if the PPVPN service that the Service Provider (SP)
provides is satisfactory.
4.1. Availability
VPN services must have high availability. VPNs that are distributed
over several sites require connectivity to be maintained even in the
event of network failures or degraded service.
This can be achieved via various redundancy techniques such as:
1. Physical Diversity
A single site connected to multiple CEs (for CE-based PPVPN) or PEs
(for PE-based PPVPNs), or different POPs, or even different service
providers
or
2. via tunnel redundancy.
4.2. Stability
In addition to availability, VPN services must also be stable.
Stability is a function of several components such as VPN routing,
signaling and discovery mechanisms, in addition to tunnel stability.
For example, in the case of routing, route flapping or routing loops
must be avoided in order to ensure stability. Stability of the VPN
service is directly related to the stability of the mechanisms and
protocols used to establish the service. It should also be possible
to allow network upgrades and maintenance procedures without
impacting the VPN service.
4.3. Traffic types
VPN services must support unicast (or point to point) traffic and
should support any-to-any or point-to-multipoint traffic including
multicast and broadcast traffic. In the broadcast model, the network
delivers a stream to all members of a subnetwork, regardless of =
their
[Page =
7]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
interest in that stream. In the multicast model, the network =
delivers
a stream to a set of destinations that have registered interest in
the stream. All destinations need not belong to the same subnetwork.
Multicast is more applicable to L3 VPNs while broadcast is more
applicable to L2VPNs. It is 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.
All PPVPN approaches shall support both IPv4 and IPv6 traffic.
Specific L2 traffic types (e.g., ATM, Frame Relay and Ethernet) =
shall
be supported via encapsulation in IP or MPLS tunnels in the case of
L2VPNs.
4.4. Data isolation
The PPVPN must support forwarding plane isolation. The network must
never deliver user data accross VPN boundaries unless the two VPNs
participate in an intranet or extranet.
Furthermore, if the provider network receives signaling or routing
information from one VPN, it must not reveal that information to
another VPN unless the two VPNs participate in an intranet or
extranet.
4.5. Security
A range of security features should be supported by the suite of
PPVPN solutions in the form of securing customer flows, providing
authentication services for temporary, remote or mobile users, and
the need to protect service provider resources involved in =
supporting
a PPVPN [VPN SEC]. Each PPVPN solution should state which security
features it supports and how such features can be configured on a =
per
customer basis. Protection against Denial of Service (DoS) attacks =
is
a key component of security mechanisms. Examples of DoS attacks
include mail spamming, access connection congestion, TCP SYN =
attacks,
ping attacks and intrusion attempts such as Trojan horse attack.
[Page =
8]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
4.5.1. User data security
PPVPN solutions that support user data security should use standard
methods (e.g., IPsec) to achieve confidentiality, integrity,
authentication and replay attack prevention. Such security methods
must be configurable between different end points, such as CE-CE, =
PE-
PE, and CE-PE. It is also desirable to configure security on a per-
route or per-VPN basis.
4.5.2. Access control
A PPVPN solution may also have the ability to activate the
appropriate filtering capabilities upon request of a customer. A
filter provides a mechanism so that access control can be invoked at
the point(s) of communication between different organizations
involved in an extranet. Access control can be implemented by a
firewall, access control lists on routers or similar mechanisms to
apply policy-based access control. Access control must also be
applicable between CE-CE, PE-PE and CE-PE.
4.5.3. Site authentication and authorization
A PPVPN solution requires authentication and authorization of the
following:
- temporary and permanent access for users connecting to sites
(authentication and authorization BY the site)
- the site itself (authentication and authorization FOR the =
site)
4.5.4. Inter domain security
The VPN solution must have appropriate security mechanisms to =
prevent
the different kinds of Distributed Denial of Service (DDoS) attacks
mentioned earlier, misconfiguration or unauthorized accesses in =
inter
domain PPVPN connections.
[Page =
9]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
4.6. Topology
A VPN should support arbitrary, customer-defined inter-site
connectivity, ranging, for example, from hub-and-spoke, partial mesh
to full mesh topology. These can actually be different from the
topology used by the service provider. To the extent possible, a
PPVPN service should be independent of the geographic extent of the
deployment.
Multiple VPNs per customer site should be supported without =
requiring
additional hardware resources per VPN. This should also include a
free mix of L2 and L3 VPNs.
To the extent possible, the PPVPN services should be independent of
access network technology.
4.7. Addressing
Each customer resource must be identified by an address that is
unique within its VPN. It need not be identified by a globally =
unique
address.
Support for private addresses as described in RFC 1918, as well as
overlapping customer addresses shall be supported.
A VPN service shall be capable of supporting non-IP customer
addresses via encapsulation techniques, if it is a Layer 2 VPN
(e.g., Frame Relay, ATM, Ethernet). Support for non-IP Layer 3
addresses may be desirable in some cases, but is beyond the scope of
VPN solutions developed in the IETF, and therefore, this document.
4.8. Quality of Service
A PPVPN shall be able to support QoS via IETF standardized =
mechanisms
such as Diffserv. Support for best-effort traffic shall be =
mandatory
for all PPVPN types.
Note that all cases involving QoS may require that the CE and/or PE
perform shaping and/or policing.
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,
and is traffic engineered or includes capacity for restoration and
growth. Hence PE-PE QoS is not a major issue. As far as access QoS =
is
[Page =
10]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
concerned, there are two directions of QoS management that should be
considered in any PPVPN service regarding QoS:
- From the CE across the access network to the PE
- From the PE across the access network to CE
PPVPN CE and PE devices should be capable of supporting QoS across =
at
least the following subset of access networks, as applicable to the
specific type of PPVPN (L2 or L3). However, to the extent possible,
the QoS capability of a PPVPN should be independent of the access
network technology:
- ATM Virtual Connections (VCs)
- Frame Relay Data Link Connection Identifiers (DLCIs)
- 802.1d Prioritized Ethernet
- MPLS-based access
- Multilink Multiclass PPP
- QoS-enabled wireless (e.g., LMDS, MMDS)
- Cable modem
- QoS-enabled Digital Subscriber Line (DSL)
Different service models for QoS may be supported. Examples of =
PPVPN
QoS service models are:
- Managed access service : Provides QoS on the access connection
between CE and the customer facing ports of the PE. No QoS support
is required in the provider core network in this case.
- Edge-to-edge QoS : Provides QoS across the provider core, =
either
between CE pairs or PE pairs, depending on the tunnel demarcation
points. This scenario requires QoS support in the provider core
network.
4.9. Service Level Agreement and Service Level Specification Monitoring
and Reporting
A Service Level Specification (SLS) may be defined per access =
network
connection, per VPN, per VPN site, and/or per VPN route. The service
provider may define objectives and the measurement interval for at
least the SLS using the following Service Level Objective (SLO)
parameters:
- QoS and traffic parameters for the Intserv flow or Diffserv
class [Y.1541]
- Availability for the site, VPN, or access connection
[Page =
11]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
- Duration of outage intervals per site, route or VPN
- Service activation interval (e.g., time to turn up a new =
site)
- Trouble report response time interval
- Time to repair interval
- Total traffic offered to the site, route or VPN
- Measure of non-conforming traffic for the site, route or VPN
- Delay and delay variation (jitter) bounds
- Packet ordering, at least when transporting L2 services
sensitive to reordering (e.g., ATM).
The above list contains items from [Y.1241], as well as other items
typically part of SLAs for currently deployed VPN services [FRF.13].
See [RFC3198] for generic definitions of SLS, SLA, and SLO.
The provider network management system shall measure, and report as
necessary, whether measured performance meets or fails to meet the
above SLS objectives.
The service provider and the customer may negotiate a contractual
arrangement that includes a Service Level Agreement (SLA) regarding
compensation if the provider does not meet an SLS performance
objective. Details of such compensation are outside the scope of =
this
document.
4.10. Network Resource Partitioning and Sharing between VPNs
Network resources such as memory space, FIB table, bandwidth and CPU
processing shall be shared between VPNs. Mechanisms should be
provided to prevent any specific VPN from taking up available =
network
resources and causing others to fail.
[Page =
12]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
5. Provider requirements
This section describes operational requirements for a =
cost-effective,
profitable VPN service offering.
5.1. Scalability
The scalability for VPN solutions has many aspects. The list below =
is
intended to comprise of the aspects that PPVPN solutions should
address. Clearly these aspects in absolute figures are very =
different
for different types of VPNs - i.e., a point to point service has =
only
two sites, while a VPLS or L3VPN may have a larger number of sites.
It is also important to verify that PPVPN solutions not only scales
on the high end, but also on the low end - i.e., a VPN with three
sites and three users should be as viable as a VPN with hundreds of
sites and thousands of users.
5.1.1. Service Provider Capacity Sizing Projections
A PPVPN solution should be scalable to support a very large number =
of
VPNs per Service Provider network. The estimate is that a large
service provider will require support for O(10^4) VPNs within four
years.
A PPVPN solution should be scalable to support a wide range of =
number
of site interfaces per VPN, depending on the size and/or structure
of the customer organization. The number of site interfaces should
range from a few site interfaces to over 50,000 site interfaces per
VPN.
A PPVPN solution should be scalable to support of a wide range of
number of routes per VPN. The number of routes per VPN may range
from just a few to the number of routes exchanged between ISPs
(O(10^5)). The high end number is especially true considering the
fact that many large ISPs may provide VPN services to smaller ISPs =
or
large corporations. Typically, the number of routes per VPN are =
twice
the number of site interfaces or larger.
A PPVPN solution should support high values of the frequency of
configuration setup and change, e.g., for real-time provisioning of
an on-demand videoconferencing VPN or addition/deletion of sites.
Approaches should articulate scaling and performance limits for more
complex deployment scenarios, such as inter-AS(S) VPNs and =
carriers'
[Page =
13]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
carrier. Approaches should also describe other dimensions of
interest, such as capacity requirements or limits, number of
interworking instances supported as well as any scalability
implications on management systems.
A PPVPN solution should support a large number of customer =
interfaces
on a single PE (for PE-based PPVPN) or CE (for CE-based PPVPN) with
current Internet protocols.
5.1.2. VPN Scalability aspects
This section describes the metrics for scaling PPVPN solutions,
points out some of the scaling differences between L2 and L3 VPNs.
Further discussion on service provider sizing projections are in
Section 5.1.1.
5.1.2.1. Number of users per site
The number of users per site follows the same logic as for users per
VPN. Further, it must be possible to have single user sites =
connected
to the same VPN as very large sites are connected to.
L3 VPNs must scale from 1 user per site to O(10^3) per site. L2 VPNs
must scale from 1 user to a O(10^2) per site.
5.1.2.2. Number of sites per VPN
The number of sites per VPN clearly depends on the number of users
per site. VPNs must scale from 2 to O(10^2) sites per VPN. These
numbers are usually limited by device memory.
5.1.2.3. Number of PEs and CEs
The number of PEs that supports the same set of VPNs, i.e., the
number of PEs that needs to directly exchange information on VPN de-
multiplexing information is clearly a scaling factor in a PE-based
VPN. Similarly, in a CE-based VPN, the number of cEs is a scaling
factor. This number is driven by the type of VPN service, and also =
by
whether the service is within a single AS/domain or involves a =
multi-
SP or multi-AS network. Typically, this number should be as low as
possible in order to make the VPN cost effective and manageable.
[Page =
14]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
5.1.2.4. Number of sites per PE
The number of sites per PE needs to be discussed based on several
different scenarios. On the one hand there is a limitation to the
number of customer facing interfaces that the PE can support. On the
other hand the access network may aggregate several sites connected
on comparatively low bandwidth on to one single high bandwidth
interface on the PE. The scaling point here is that the PE must be
able to support a few or even a single site on the low end and
O(10^4) sites on the high end. This number is also limited by device
memory. Implementations of PPVPN solutions may be evaluated based on
this requirement, because it directly impacts cost and manageability
of a VPN.
5.1.2.5. Number of VPNs in the network
The number of VPNs should scale linearly with the size of the access
network and with the number of PEs. As mentioned in Section 5.1.1,
the number of VPNs in the network should be O(10^4). This =
requirement
also effectively places a requirement on the number of tunnels that
must be supported in the network. For a PE-based VPN, the number of
tunnels is of the same order as the number of VPNs. For a CE-based
VPN, the number of tunnels in the core network may be fewer, because
of the possibility of tunnel aggregation or multiplexing across the
core.
5.1.2.6. Number of VPNs per customer
For a large it is fully conceivable that the number of VPNs could be
fairly large, both service diversification and separation of
different work groups contributes to this. It is possible that one
customer will run up to O(100) VPNs.
5.1.2.7. Number of addresses per VPN
Since any VPN solution shall support private customer addresses, the
number of addresses supported for a L3 VPN needs to scale from very
few (for smaller customers) to very large numbers seen in typical
Service Provider backbones. The high end is especially true
considering that many Tier 1 SPs may provide VPN services to Tier 2
SPs or to large corporations. For a L2 VPN this number would be on
the order of addresses supported in typical native Layer 2 =
backbones.
[Page =
15]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
5.1.3. Solution-Specific Metrics
Each PPVPN solution shall document its scalability characteristics =
in
quantitative terms. Some examples are provided below as an
illustration.
The following example applies to the number of tunnels necessary in
various devices in the network. In a PE-based VPN, edge-to-edge
tunnels (PE-to-PE) need to be established, while in a CE-based VPN,
end-to-end tunnels between pairs of CEs are necessary. Therefore,in
general, PE-based VPNs scale better than CE-based VPNs, although the
scalability of CE-based VPNs may be improved by tunnel aggregation
between PEs.
A scalable PE-based solution should quantify the amount of state =
that
a PE and P device must support. This should be stated in terms of =
the
total number of VPNs and site interfaces supported by the service
provider. Ideally, all VPN-specific state should be contained in =
the
PE device for a PE-based VPN. Similarly, all VPN-specific state
should be contained in the CE device for a CE-based VPN. In all
cases, the backbone routers (P devices) shall not maintain VPN-
specific state as far as possible.
Another metric is that of complexity. In a PE-based solution the PE
is more complex in that it must maintain tunnel-specific information
for each VPN, but the CE is simpler since it does not need to =
support
tunnels. On the other hand, in a CE-based solution, the CE is more
complex since it must implement routing across a number of tunnels =
to
other CEs in the VPN, but the PE is simpler since it has only one
routing and forwarding instance.
A CE-based solution should quantify the state and scaling limits.
This should be stated in terms of the number of tunnels supported,
how these tunnels are provisioned and maintained (e.g., key
exchange), how routing occurs across these tunnels, and what the
impact of changes in the network topology do to the convergence
performance of such a solution.
5.2. Management
A service provider must have a means to view the topology,
operational state, service order status, and other parameters
associated with each customer's VPN. Furthermore, the service
provider must have a means to view the underlying logical and
physical topology, operational state, provisioning status, and other
parameters associated with the equipment providing the VPN =
service(s)
[Page =
16]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
to its customers.
VPN devices should provide standards-based management interfaces
wherever feasible.
5.2.1. Customer Management of a VPN
A customer must have a means to view the topology, operational =
state,
service order status, and other parameters associated with his or =
her
VPN.
All aspects of management information about CE devices and customer
attributes of a PPVPN manageable by an SP should be capable of being
configured and maintained by the customer after being authenticated
and authorized.
A customer should be able to make dynamic requests for changes to
traffic parameters. A customer should be able to receive real-time
response from the SP network in response to these requests. One
example of such as service is a "Dynamic Bandwidth management"
capability, that enables real-time response to customer requests for
changes of allocated bandwidth allocated to their VPN(s).
6. Engineering requirements
These requirements are driven by implementation characteristics that
make service and provider requirements achievable.
6.1. Forwarding plane requirements
VPN solutions should not pre-suppose or preclude the use of IETF
developed tunneling techniques such as IP-in-IP, L2TP, GRE, MPLS or
IPsec. The separation of VPN solution and tunnels will facilitate
adaptability with extensions to current tunneling techniques or
development of new tunneling techniques. It should be noted that the
choice of the tunneling techniques may impact the service
capabilities of the VPN solution.
For Layer 2 VPNs, solutions should utilize the encapsulation
techniques defined by PWE3, and should not impose any new
requirements on these techniques.
PPVPN solutions must not impose any restrictions on the backbone
traffic engineering and management techniques. Conversely, backbone
[Page =
17]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
engineering and management techniques must not affect the basic
operation of a PPVPN, apart from influencing the SLA/SLS guarantees
associated with the service. The SP should, however, be required to
provide per-VPN management, tunnel maintenance and other maintenance
required in order to meet the SLA/SLS.
By definition, VPN traffic should be segregated from each other, and
from non-VPN traffic in the network. After all, VPNs are a means of
dividing a physical network into several logical (virtual) networks.
VPN traffic separation should be done in a scalable fashion. =
However,
safeguards should be made available against misbehaving VPNs to not
affect the network and other VPNs.
A VPN solution should not impose any hard limit on the number of =
VPNs
provided in the network.
6.2. Control plane requirements
The plug and play feature of a VPN solution with minimum
configuration requirements is an important consideration. The VPN
solutions should have mechanisms for protection against customer
interface and/or routing instabilities so that they do not impact
other customers' services.
A VPN should be provisioned with minimum number of steps. For
instance,a VPN need not be configured in every PE. For this to be
accomplished, an auto-configuration and an auto-discovery protocol,
which should be as common as possible to all VPN solutions, should =
be
defined. However, these mechanisms should not adversely affect the
cost, scalability or stability of a service by being overly complex,
or by increasing layers in the protocol stack.
Mechanisms to protect the SP network from effects of =
misconfiguration
of VPNs should be provided.
6.3. Control Plane Containment
The PPVPN control plane must include a mechanism through which the
service provider can filter PPVPN related control plane information
as it passes between Autonomous Systems. For example, if a service
provider supports a PPVPN offering, but the service provider's
neighbors do not participate in that offering, the service provider
should not leak PPVPN control information into neighboring networks.
Neighboring networks must be equipped with mechanisms that filter
this information should the service provider leak it.
[Page =
18]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
6.4. Requirements related to commonality of PPVPN mechanisms with each
other and with generic Internet mechanisms
As far as possible, the mechanisms used to establish a VPN service
should re-use well-known IETF protocols, limiting the need to define
new protocols from scratch. It should, however, be noted that the =
use
of Internet mechanisms for the establishment and running of an
Internet-based VPN service, shall not affect the stability,
robustness, and scalability of the Internet or Internet services. In
other words, these mechanisms should not conflict with the
architectural principles of the Internet, nor should it put at risk
the existing Internet systems. For example, IETF-developed routing
protocols should be used for routing of L3 PPVPN traffic, without
adding VPN-specific state to the Internet core routers. Similarly,
well-known L2 technologies should be used in VPNs offering L2
services, without imposing risks to the Internet routers. A
solution must be implementable without requiring to add additional
funcionality to the P devices in a network, and minimal =
functionality
to!
the PE in a PE-based VPN and CE in a CE-based VPN.
In addition to commonality with generic Internet mechanisms,
infrastructure mechanisms used in different PPVPN solutions (both L2
and L3), e.g., discovery, signaling, routing and management, should
be as common as possible.
6.5. Interoperability
Each technical solution is expected to be based on interoperable
Internet standards.
Multi-vendor interoperability at network element, network and =
service
levels among different implementations of the same technical =
solution
should be ensured (that will likely rely on the completeness of the
corresponding standard). This is a central requirement for SPs and
customers.
The technical solution must be multi-vendor interoperable not only
within the SP network infrastructure, but also with the customer's
network equipment and services making usage of the PPVPN service.
Customer access connections to a PPVPN solution may be different at
different sites (e.g., Frame Relay on one site and Ethernet on
another).
Interconnection of a L2VPN over an L3VPN as if it were a customer
[Page =
19]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
site shall be supported. However, interworking of Layer 2
technologies is not required, and is outside the scope of the =
working
group, and therefore, of this document.
Inter-domain interoperability - It should be possible to deploy a
PPVPN solution across domains, Autonomous Systems, or the Internet.
7. Security Considerations
This document does not have any security considerations other than
the security requirements described in Section 4.5.
8. References
8.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process - =
Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[TERMINOLOGY] Andersson, L., Madsen, T., "Terminology for Provider
Provisioned Virtual Private Networks", work in =
progress
[L3FRAMEWORK] Callon, R., Suzuki, M., et al. "A Framework for
Layer 3 Provider Provisioned Virtual Private =
Networks",
work in progress
[L2FRAMEWORK] Andersson, L., et al. "A Framework for Layer 2 =
Provider
Provisioned Virtual Private Networks", work in =
progress
8.2. Informative References
[L3REQTS] Carugi, M., McDysan, D. et al., "Service =
Requirements
for Layer 3 Provider Provisioned Virtual Private
Networks", work in progress
[L2REQTS] Augustyn, W., Serbest, Y., et al., "Service =
Requirements
for Layer 2 Provider Provisioned Virtual Private
Networks", 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] Knightson, K. (editor), "Network based IP VPN =
Service
[Page =
20]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
- Generic Framework and Service Requirements ", =
Y.1311
ITU-T Recommendation, May 2001
[RFC 3198] A. Westerinen et al, "Terminology for Policy-Based
Management," November, 2001.
[VPN SEC] J. De Clercq et al, "Considerations about possible
security extensions to BGP/MPLS VPN," work in =
progress.
[FRF.13] Frame Relay Forum, "Service Level Definitions
Implementation Agreement," August, 1998.
[Y.1541] "Network Performance Objectives for IP-based
Services," Y.1541, ITU-T Recommendation.
9. Acknowledgements
This work was done in consultation with the entire design team for
PPVPN requirements. A lot of the text was adapted from the Layer 3
requirements document produced by Layer 3 requirements design team.
The authors would also like to acknowledge the constructive feedback
from Alex Zinin.
10. Editor's Address
Ananth Nagarajan
Sprint
6220 Sprint Parkway
Overland Park, KS 66251
USA
E-mail: ananth.nagarajan@mail.sprint.com
[Page =
21]
Internet Draft draft-ietf-ppvpn-generic-reqts-02.txt Jan =
2003
11. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 in 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.
[Page =
22]
------_=_NextPart_000_01C2BCBC.47FBD95A--