PPVPN Working Group Loa Andersson
Internet-Draft Utfors AB
Expiration Date: December 2002
28 June, 2002
Parameters and related metrics to compare PPVPN Layer 2 solutions
<draft-andersson-ppvpn-metrics-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [rfc2026].
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.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Summary for Sub-IP related Internet Drafts
RELATED DOCUMENTS:
Section 5 lists an extensive list of current drafts submitted to the
PPVP WG.
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
This ID is intended for the PPVPN WG.
WHY IS IT TARGETED AT THIS WG(s)
INTERNET-DRAFT draft-andersson-ppvpn-terminolgy-01.txt 28 June, 2002
Andersson Expires December 2002 [Page 2]
The PPVPN WG deals with provider provisioned VPNs. This document
describes metrics for Layer 2 Provider Provisioned Virtual Private
Network services, a class of Provider Provisioned Virtual Private
Networks services.
JUSTIFICATION
This document describes some parameters and related metrics which could
be used for classifying solutions in the Layer 2 space and, possibly,
for evaluating commonalities and differences, pros and cons of the
functional options specific to each solution.
As complementary result, the document aims to provide input to the PPVPN
WG for further definition of a limited set of candidate solutions in the
Layer 2 solution space, promoting commonalities and convergence among
solutions in respect of the key service requirements.
The parameters and related metrics under consideration are inspired from
the appropriate service requirement drafts ([L2VPN-REQ], etc.) and are
then relevant for evaluating the Layer 2 VPN solutions against
significant requirements for customers and service providers. In this
perspective, the metrics will be also aligned with the PPVPN
Applicability Statement Guidelines document [APPL-GUIDE] and will
provide input for each candidate solution-specific Layer 2 Applicability
Statement.
The extension of this document to Layer 3 VPNs in a further version has
to be evaluated.
Abstract
The PPVPN working group deals with provider provisioned VPNs. This
document describes metrics primarily for Layer 2 Virtual Private
Networks, to be used in comparing solutions proposal and later when
comparing new proposals to the existing.
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 [rfc2119].
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 3]
Contents
1. Introduction...................................................... 4
2. Metrics........................................................... 4
2.1 Type Service.................................................. 5
2.2 Provisioning.................................................. 5
2.3 Discovery..................................................... 6
2.4 VPN "Signaling"............................................... 7
2.5 Coupling...................................................... 8
3. Reference tree.................................................... 8
3.1 Classification Tree........................................... 8
4. Non-metrics...................................................... 10
4.1 Tunnel technology............................................ 10
4.2 Security..................................................... 10
5. List of Layer 2 VPN drafts....................................... 10
6. Metrics and parameter matrix..................................... 15
6.1 Service quality.............................................. 15
6.2 Scaling...................................................... 16
6.3 SLA enforcements............................................. 17
6.4 Inter-domain reachability.................................... 18
6.5 Provisioning cost/complexity................................. 18
6.6 Flexibility.................................................. 19
6.7 Integration and migration.................................... 19
6.8 Value-add services........................................... 20
6.9 Cost......................................................... 20
7. Summary and recommendations...................................... 21
7.1 Documents for VPLS type of services.......................... 21
7.2 Document for VPWS type of services:.......................... 21
7.3 Protocol extensions.......................................... 21
7.4 Architecture and Framework................................... 22
8. Security......................................................... 22
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 4]
1. Introduction
The Provider Provisioned VPN solutions have attracted a great deal of
interest and several solutions have been proposed. There is clearly a
need for an organized way of comparing the solutions and elements in the
solutions. This document proposes such a method; it is based on some
generic elements that have to be present/solved by every VPN
implementation. This version of the draft is very much focused on the L2
VPNs, and that is natural since it comes out of a L2 VPN design team
effort. The L3 parts of this document is included to only show the
potential to include a more extensive treatment of L3 VPNs in the
future.
Concepts and terminology in this document are according to [TERM].
2. Metrics
When implementing customer VPNs in a provider network a certain set of
metrics has to be considered, see e.g. [L2VPN-REQ], in future versions
of this document further references will be added, e.g. other
requirement documents and Applicability Statement Guidelines document.
Examples of such metrics are:
- service quality
- scaling, e.g. number of nodes per VPN, number of nodes per site or
number of VPN per network
- SLA enforcements
- inter-domain reachability
- provisioning cost/complexity
- flexibility
- integration with and migration from existing infrastructure and
services
- value-add services
- cost
- etc.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 5]
In deciding which solution to be implemented in a given situation the
relevant metrics for each of the parameters below could be considered.
2.1 Type Service
Currently we see three different types of provider provisioned VPN
services, Layer 3 VPN, Virtual Private Wire Service (VPWS) and Virtual
private LAN Service (VPLS). A framework for L3-VPNs is found in [L3-
FRMWRK] and a framework for Layer 2 VPNs is found in [L2-FRMWRK]. The
[L2-FRMWRK] also opens up for a discussion of an IP-only LAN-like
Service (IPLS), however this is for further discussion. A joint name for
the VPLS and the VPWS is Layer 2 VPNs, potentially the IPLS will be
included in this group.
2.1.1 Layer3 VPN
A L3 VPN is an IP routed network, where addresses could be either from
the public or private address space. Being a routed service it will
scale based on how many routes the Provider Edge routers (PE) are able
to handle in their VRFs. Scaling properties are very good for L3VPN, and
is not in general dependent on standards or specification, but rather on
the networking equipment or network(s) it is implemented.
More detailed treatment of L3 VPNs are for future versions of this
document.
2.1.2 Virtual Private Wire Service (VPWS)
A VPWS is a VPN service that supplies a L2 point-to-point service across
a Wide Area Network (WAN) or a Metropolitan Area Network (MAN). Being a
point-to-point service where there are very few scaling issues with the
service as such. Scaling issues might arise from the number of end-
points that can be supported on a particular PE.
2.1.3 Virtual Private LAN Service (VPLS)
A VPLS is an L2 service that in all respects emulates LAN across a Wide
Area Network (WAN) or a Metropolitan Area Network (MAN). Thus it also
has all the scaling characteristics of a LAN. Other scaling issues might
arise from the number of end-points that can be supported on a
particular PE.
2.2 Provisioning
It is critical to limit the time and effort that a service provider
needs to spend on provisioning customer VPNs.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 6]
2.2.1 Static
We say that a VPN is static configured if all information ¡ attachment
circuits, tunnels, routing/forwarding information, QoS parameters, etc.
¡ are manually configured at each node participating in the VPN service.
2.2.2 Automatic
In an automatic configured network it is possible to enter configuration
parameters on one single spot, e.g. the PE.
2.3 Discovery
Discovery involves discovering e.g. VPNs and VPN end-points, in such a
way that they may be connected to the VPN. The most important parameter
in comparing different discovery mechanisms is the time it takes from
that the information is configured until all nodes that need to know it
has that information.
2.3.1 BGP
A basic function in BGP is to advertise information BGP speaking peers.
In VPN solutions MP-BGP is used to distribute information that is used
in a PE to map traffic from an attachment circuit to a PE-to-PE tunnel
and which de-multiplexor to use, and vice versa.
The scaling issues in using BGP as discovery protocol are few. The
number of VPNs in a network, the number of hosts per site, the number of
sites per VPN and number of VPN instances per PE is not in any way
limited by the use of BGP.
2.3.2 Directory based
In a directory based solution the information needed by a PE to set up
tunnels and de-multiplexors are configured in a directory, the Pes
supporting a particular VPN then can and go look up the information
needed to establish the connectivity and other configuration information
needed for that VPN.
Note: For a future treatment of L3 VPNs discovery by means of Multicast
IGP has to be added.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 7]
2.4 VPN "Signaling"
VPN Signaling involves distributing information between PEs so the PE
can take a local decision on setting up tunnels and distributing de-
multiplexors correctly for the Layer 2 VPN sites connected to the PE.
2.4.1 L2TP
Extension to L2TP to make is possible to signal information between Pes
for establishing de-multiplexors has been presented in [L2TP].
2.4.2 RSVP-TE
RSVP-TE (RSVP Tunnel Extensions) is a protocol that was developed to set
up LSPs with certain constraints, e.g. bandwidth and/or explicit routes.
There are proposals to use RSVP-TE in situations where only a few VPNs
are present and where QoS parameters are important.
2.4.3 LDP
Label Distribution Protocol (LDP) is a protocol that has been developed
to distribute MPLS labels within a domain. LDP has no method defined for
carrying explicit routes or QoS information.
The targeted LDP makes it possible to communicate between two non-
adjacent LSRs to set up de-multiplexors between Pes. LDP has a reliable
delivery mechanism since it is based on TCP.
Main benefit by using LDP is that it is readily available in almost any
MPLS enabled IP network.
In the context of provider provisioned VPNs there are few scaling issues
with LDP, LDP has however not a method to carry information across AS
borders.
2.4.4 BGP
BGP is a protocol that in the context of VPNs is used both for discovery
and to signal necessary information (e.g. de-multiplexors) to set up
end-to-end connectivity across the core network tunnels. For signalling
purposes it is the Multi-Protocol extensions to BGP (MP-BGP) that is
used. BGP has a reliable delivery mechanism since it is based on TCP.
Main benefits by using BGP are that it has become a common denominator
in networks that run MPLS based VPNs and that it by its nature is
possible to use for Inter-Domain areas.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 8]
In the context of provider provisioned VPNs there are few scaling issues
with MP-BGP.
2.5 Coupling
The concept of "coupling" relates to Layer 2 VPNs and how the
functionality needed for the service is allocated relative to the Pes;
it describes e.g. how MAC-learning and signalling functions are
distributed across different devices.
2.5.1 Coupled
In a coupled situation all functions are located on the same physical
device.
2.5.2 De-coupled
In a de-coupled situation functions are distributed across at least two
different physical devices.
De-coupled solutions are found in [DTLS] and [LPE], taxonomy and
terminology for de-coupled solutions is found in [TERM].
3. Reference tree
By using the parameters discussed in section 2 it is possible to create
a decision tree that can be used to classify the existing VPN proposals.
By traversing the tree from top to bottom a short hand description of
the solution is created and could easily be compared with other
solutions.
3.1 Classification Tree
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 9]
Type of Service L3VPN VPW VPLS
| | | | | |
| +-------------------+-+-------+ | |
| | | | | |
+-----------+ +-----+-+-------+--------+ |
| +-+-----+ | |
| | | +-----+ | +-------+
| | | || |
v v v vv v
Provisioning Static Automatic
| | | |
| +--------------+ | |
| | | |
| | | |
| | | |
| +--------------+-+ |
| | | |
v v v v
Discovery BGP Directory based
|||| | | | |
+----------+||+----------------+-+-+-+-+
| || | | | | |
| |+-----------+ | | | | |
|+----------+------------+-----+ | | | |
|| |+-----------+-------+ | | |
|| || |+--------+ | |
|| || || | |
vv vv vv v v
Signalling L2TP RSVP-TE LDP BGP
| | | | | | ||
| +---------+-+----------+-+------+ ||
| | | | | | ||
+--------+ | +----------+ +---+ | ||
| | | | | | ||
| | +---------+-+---+--+--+|
| | | | | | | |
| | |+--------+ +---+--+--+|
| | || | | ||
| | || | | ||
v v vv v v vv
Coupling Coupled De-Coupled
Note: The L3 branch is in the tree for further study only.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 10]
4. Non-metrics
Some of the issues that may seem obvious to consider when deciding how
to deploy a VPN are considered to be outside the scope of this document.
Some of those are listed here.
4.1 Tunnel technology
Most VPNs are implemented by means of a set of tunnels between the PEs
of that service. Tunnel technology and the methods to signal the set up
of the tunnel are outside the scope of this document. The establishment
of the tunnel is viewed as inherent to the network; it is even
conceivable that different "legs" of the VPN might use different tunnel
technologies.
4.2 Security
VPN technologies supply a traffic separation between customers and
customer services. This is the same level of traffic separation that
e.g. is supplied by traditional WAN technology based VPNs. Further
security mechanisms, e.g. encryption is outside the scope of this
document.
5. List of Layer 2 VPN drafts
In this section the current drafts addressed to the ppvpn working group
is classified according to the parameters in the classification tree in
section 3. As documents do not address every aspect of a VPN some
entries says Not Applicable (NA). Sometimes what is describe in the
document are equally applicable to all the values a parameter make take,
those entries says "All". For the aspects that are discussed in the
document specific values are entered.
Note: For version ¡01 this process is not completed, the the list of
Layer 2 VPN drafts needs to be further discussed and agreed upon.
draft-ietf-ppvpn-bgpvpn-auto-02.txt
This draft defines a BGP based auto-discovery mechanism for both
Layer 2 VPNs and Layer 3 VPNs. This mechanism is based on the
approach used by RFC2547-bis for distributing VPN routing
information within the service provider(s). Each VPN scheme uses
the mechanism to automatically discover the information needed by
that particular scheme.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 11]
Classification:
Type of Service: All
Provisioning: NA
Discovery: BGP
Signalling: NA
Coupling: NA
draft-ietf-ppvpn-l2vpn-00.txt
This document discusses the signalling, encapsulation, and
configuration issues that arise. Its purpose is to provide an
architecture which allows different kinds of point-to-point
virtual circuits to be provided through different kinds of IP
tunnels.
Classification:
Type of Service:
Provisioning:
Discovery:
Signalling:
Coupling: NA
draft-augustyn-vpls-arch-00.txt
This document describes the architecture and model for Virtual
Private LAN Services (VPLS) and discusses the signalling,
encapsulation, and configuration issues that arise.
draft-augustyn-vpls-bw-00.txt
This document describes a method for controlling customer traffic
for L2 VPN services which support broadcast, multicast or implied
broadcast such as e.g. VPLS.
draft-augustyn-vpls-requirements-02.txt
This document specifies requirements for a VPLS, the intention is
to extend it to comprise all types of Layer 2 VPNs.
draft-cai-ppvpn-vc-rsvp-te-00.txt
This draft discusses the use of RSVp-TE as a VC setup mechanism.
draft-chen-ppvpn-dvpls-compare-00.txt
This draft compares different solutions for decouple PE
functionality in a VPLS. It advocates a merging of existing
drafts.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 12]
draft-elwin-l2tpext-ppvpn-00.txt
PPVPNs need a tunneling mechanism and a means to automatically
discover VPN membership and signal these tunnels. This draft
elaborates the use of L2TP as the tunneling mechanism, and defines
extensions to L2TP to handle VPN membership discovery to leverage
PPVPNs.
draft-elwin-ppvpn-l2tp-arch-00.txt
This document discusses the use of L2TP for establishing PPVPNs.
It proposes to use L2TP for VPN membership, topology discovery,
and as a tunnelling mechanism.
draft-heinanen-dirldp-uni-vc-vpns-01.txt
This document describes how provider based unidirectional Virtual
Circuit VPNs can be implemented using a directory (such as DNS)
and LDP for PE discovery and label distribution.
draft-Heinanen-dns-ldp-vpls-00.txt
This document describes how provider provisioned Virtual Private
LAN Service (VPLS) can be implemented using DNS and LDP for PE
discovery and label distribution.
draft-heinanen-inarp-uni-01.txt
This document describes operation of an Inverse Address Resolution
Protocol (InARP) over unidirectional virtual circuits such as MPLS
LSPs.
draft-khandekar-ppvpn-hvpls-mpls-00.txt
This document proposes extensions to draft-lasserre-vkompella-
ppvpn-tls-00.txt, by introducing hierarchical connectivity. This
document also describes support for participation of non-bridging
PE devices in a VPLS solution.
draft-knight-l2vpn-lpe-ad-00.txt
This document describes a lightweight protocol for VPLS
information exchange between Logical PE components, consisting of
the PE-Edge (i.e. in the terminology of [TERM] the User facing-PE
(U-PE)) and PE-Core (i.e. in the terminology [TERM] of the Network
facing-PE (N-PE)).
draft-kompella-ppvpn-dtls-01.txt
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 13]
In a VPLS a common scenario is when Service Provider in a metro
area places a simple, low-cost box (MTU, i.e. in the terminology
of [TERM] a User facing-PE (U-PE)) in each building; these MTUs
have uplinks to some box (PE, i.e. in the terminology of [TERM] a
Network facing-PE (N-PE)) in one or more provider site. The
document describes decoupling the functions needed to offer the
VPLS across the MTU and PE.
draft-kompella-ppvpn-l2vpn-01.txt
This document present a Layer 2 VPN solution where from the
customer's point of view, the VPN is based on Layer 2 circuits,
but the Service Provider maintains and manages a single network
for IP, IP VPNs, and Layer 2 VPNs.
draft-kompella-ppvpn-vpls-00.txt
In the case of a VPLS, a point to multipoint network connects the
customers in the VPN. This document describes the functions needed
to offer a VPLS, and propose a mechanism for signaling a VPLS, and
a mechanism for transport of VPLS frames over tunnels across a
packet switched network.
draft-lasserre-vkompella-ppvpn-tls-00.txt
This document describes a VPLS solution over MPLS. VPLS simulates
an Ethernet virtual 802.1d bridge for a given set of users. It
deliver a layer 2 broadcast domain that is fully capable of
learning and forwarding on Ethernet MAC addresses that is closed
to a given set of users.
draft-lau-ppvpn-qos-tls-mpls-00.txt
draft-lasserre-vkompella-ppvpn-vpls-00.txt describes a solution to
support point-to-multipoint VPLSs over MPLS. This document
describes two extensions to facilitate the provisioning and
support of QoS in VPLS over MPLS. The use of the VCID field in the
VC-FEC is extended to identify a VPN endpoint. One VC-label per
source/destination VPN endpoint pair is used.
draft-luciani-ppvpn-vpn-discovery-01.txt
This document describes the use of DNS to discovery VPN endpoints.
draft-martini-l2circuit-encap-mpls-04.txt
This document describes methods for encapsulating the Protocol
Data Units (PDus) of layer 2 protocols such as Frame Relay, ATM,
or Ethernet for transport across an MPLS or IP network.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 14]
draft-martini-l2circuit-trans-mpls-08.txt
This document describes methods for transporting the Protocol Data
Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5,
Ethernet, and providing a SONET circuit emulation service across
an MPLS network.
draft-menezes-inter-city-man-mpls-00.txt
This document describes a network service model for high-speed
Metropolitan Area Network (MAN) service providers to services
between cities. It simplifies MAN operation and improves the
scalability of a traditional standard overlay model by allowing
the MAN provider to peer to the NSP for both Internet transit and
inter-city MAN services (e.g. a VPLS).
draft-ouldbrahim-bgpgmpls-ovpn-02.txt
This document describes a method for how a service provider
network that offers Optical/TDM Virtual Private Network service.
draft-ouldbrahim-l2vpn-lpe-01.txt
In a VPLS a common scenario is when Service Provider in a metro
area places a simple, low-cost box Edge-PE (i.e. in the
terminology of [TERM] a User facing-PE (U-PE)) in each Building;
these Edge-PEs have uplinks to some box Core-PE (i.e. in the
terminology of [TERM] the Network facing-PE) in one or more
provider sites. This document describes decoupling the functions
needed to offer the VPLS across the Edge-PEs and Core-PE.
draft-rosen-ppvpn-l2-signaling-01.txt
This draft describes a signaling technique that eliminates the
requirement for a priori knowledge of a common VC identifier, and
to eliminate the requirement that each endpoint be known to The
other.
draft-sajassi-vpls-architectures-00.txt
In this document a reference architecture for VPLS systems is
defined. It describes possible VPLS architectures based on this
reference architecture and the logical components of each.
draft-senevirathne-vmi-frame-02.txt
This document presents a framework for a VPLS and a point-to-point
Layer 2 VPN service.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 15]
draft-shah-ppvpn-arp-mediation-00.txt
This draft specifies the procedures, which the Provider Edge
routers should perform in order to allow correct operation of
address resolution across heterogeneous point-to-point links.
draft-shah-ppvpn-vpls-pe-mtu-signaling-00.txt
draft-kompella-ppvpn-dtls-01.txt identifies the need for an
information exchange mechanism between a PE device (i.e. in the
terminology of [TERM] the Network facing-PE) and its adjunct L2PE
devices (i.e. in the terminology of [TERM] the User facing-PE) in
the decoupled VPLS. This draft proposes an LDP based approach for
such exchange mechanisms.
draft-tsenevir-gre-vpls-00.txt
In this document a VPLS solution that use GRE and IP tunnels is
described.
6. Metrics and parameter matrix
In this section each of the parameters in section 2.1 to 2.5 is examined
according to the metrics in the classification tree section (section 3).
6.1 Service quality
Service quality has many aspects, there are traffic related aspects e.g.
bandwidth, delay and jitter (depending on context called QoS, ToS or
CoS. There are also other aspects as availability, fail over times,
start up times, activation time and delivery times.
6.1.1 Type of Service
Type of service and service quality is closely connected. The inter
relationship is for further study.
6.1.2 Provisioning
There is no reason to suspect that the method chosen to provision the
VPN will have an impact service quality once the necessary connectivity
has been established.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 16]
6.1.3 Discovery
There is no reason to suspect that the method of discovery will effect
the service quality once a VPN member is discovered and properly
attached to the VPN.
It is possible that availability and activation times could be affected
by the choice of discovery mechanism.
6.1.4 Signalling
There is no reason to suspect that the method chosen to set up
pseudowires will have an impact service quality once the pseudowire has
been established.
One possible effect of the selection of method for distributing de-
multiplexors for solutions where recovery is done on a post facto basis
is that fail over times may be effected.
6.1.5 Coupling
There is no reason to suspect that whethere the PE is of a coupled or
de-coupled type will have an impact service quality, given that the
connectivity is feasible.
6.2 Scaling
Scaling is one of the most discussed aspects of Layer 2 VPNs, and
especially VPLS solutions. It is the stated goal of most VPLS solutions
to scale in the same manner as traditional LAN. There are also other
scaling aspects that are of interest, e.g. number of nodes (mac
addresses) per VPN, number of sites per VPN, or number of VPNs in an
operator network.
6.2.1 Type of Service
Clearly a Layer 3 VPN has other internal scaling properties than a Layer
2 VPN, communication is based on IP routing and routers that split the
network up to a manageable size. Scaling in terms of supporting a high
number of Layer 2 VPNs or Layer 3 VPNs, or a combination of them, in a
provider network are very similar.
6.2.2 Provisioning
The scaling issues when it comes to provision different types of VPNs
depends on how many nodes one "has to touch". A system there one need to
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 17]
configure every node and set up every tunnel, PW and attachment circuit
separately and manually, for each node that is added to the VPN, has
very different scaling characteristics as compared to a system where one
configure the relevant information on the node once you have decided
that it supports a specific VPN.
6.2.3 Discovery
For further study (FFS).
6.2.4 Signalling
There are two different aspects of signalling (de-multiplexor
distribution) that needs to be discussed. First how the de-multiplexor
systems are supported and second the result of the signalling.
A de-multiplexor distribution system that is based on running a peering
process between two PEs that needs to exhange de-multiplexors, in
combination with PEs that only support a limit number of such processes
will run into scaling problems.
6.2.5 Coupling
FFS.
6.3 SLA enforcements
FFS.
6.3.1 Type of Service
FFS.
6.3.2 Provisioning
FFS.
6.3.3 Discovery
FFS.
6.3.4 Signalling
FFS.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 18]
6.3.5 Coupling
FFS.
6.4 Inter-domain reachability
FFS.
6.4.1 Type of Service
FFS.
6.4.2 Provisioning
FFS.
6.4.3 Discovery
FFS.
6.4.4 Signalling
FFS.
6.4.5 Coupling
FFS.
6.5 Provisioning cost/complexity
FFS.
6.5.1 Type of Service
FFS.
6.5.2 Provisioning
FFS.
6.5.3 Discovery
FFS.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 19]
6.5.4 Signalling
FFS.
6.5.5 Coupling
FFS.
6.6 Flexibility
FFS.
6.6.1 Type of Service
FFS.
6.6.2 Provisioning
FFS.
6.6.3 Discovery
FFS.
6.6.4 Signalling
FFS.
6.6.5 Coupling
FFS.
6.7 Integration and migration
FFS.
6.7.1 Type of Service
FFS.
6.7.2 Provisioning
FFS.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 20]
6.7.3 Discovery
FFS.
6.7.4 Signalling
FFS.
6.7.5 Coupling
FFS.
6.8 Value-add services
FFS.
6.8.1 Type of Service
FFS.
6.8.2 Provisioning
FFS.
6.8.3 Discovery
FFS.
6.8.4 Signalling
FFS.
6.8.5 Coupling
FFS.
6.9 Cost
FFS.
6.9.1 Type of Service
FFS.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 21]
6.9.2 Provisioning
FFS.
6.9.3 Discovery
FFS.
6.9.4 Signalling
FFS.
6.9.5 Coupling
FFS.
7. Summary and recommendations
>From the number of Internet draft on requirements, architectures and
solutions seen in the Layer 2 VPN area it is possible to draw the
conclusion that there is a high degree on commonalties and a great
interest in this area.
Within the PPVPN WG it is a common understanding that the existing set
of solutions need to be limited to a more manageable set of unified
solutions.
7.1 Documents for VPLS type of services
This for a future version of this document.
7.2 Document for VPWS type of services:
This for a future version of this document.
7.3 Protocol extensions
To the extent extensions are needed for protocol that originates from
other working groups than PPVPN they should be handled in separate
documents.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 22]
7.4 Architecture and Framework
Architecture and framework issues on a general level for L2 PPVPNs
should be consolidated and incorporated in this document.
8. Security
This is a document that outlines how to compare solutions in the L2 VPN
space; while security considerations might be an issue in such a
comparison the document in itself does not introduce or address security
considerations.
Acknowledgements
This document is the outcome of discussions within the PPVPN L2 VPN
design team. The design team includes M Lassere, V Kompella, J Heinanen,
K Kompella, E Rosen, M Borden, L Andersson, P Menezes, H Ould-Brahim and
W Augustyn.
Authors' Contact
Loa Andersson
Utfors AB
R
sundavgen 12, PO Box 525
SE-169 29 Solna, Sweden
phone: +46 8 5270 5038
loa.andersson@utfors.se
References
[rfc2026]
Bradner, S. "The Internet Standards Process -- Revision 3", rfc
2026, October 1996.
[rfc2119]
Bradner, S. "Key words for use in RFCs to Indicate Requirement
Levels", rfc 2119, March 1997.
[TERM]
Andersson, L. and Madsen T. "VPN Terminology", draft-andersson-
ppvpn-terminology-01.txt", Work in Progress, Internet Draft, Jun
2002.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02
Andersson Expires December 2002 [Page 23]
[L3-FRMWRK]
Callon, R. et.al. "A Framework for Layer 3 Provider Provisioned
Virtual Private Networks", <draft-ietf-ppvpn-framework-04.txt>,
Work in Progress, Internet Draft, February 2002.
[L2TP]
Elwin, E. and Gowda, N. "L2TP Extensions for PPVPN", <draft-
elwin-l2tpext-ppvpn-00.txt>, Work in Progress, Internet draft,
November 2001.
[DTLS]
Kompella, K et.al "Decoupled Virtual Private LAN Services" draft-
kompella-ppvpn-dtls-01.txt, Work in progress, Internet Draft,
November 2001.
[LPE]Ould-Brahim, H et.al "VPLS/LPE L2VPNs: Virtual Private LAN
Services using Logical PE Architecture" draft-ouldbrahim-l2vpn-
lpe-01.txt, Work in Progress, Internet Draft, November 2001.
[L2VPN-REQ]
Augustyn, W. et al "Requirements for Layer 2 Virtual Private
Network Services (L2VPN)", draft-augustyn-ppvpn-l2vpn-
requirements-00.txt, Work in progress, Internet Draft, Jun 2002
[APPL-GUIDE]
Sumimoto, J. et al "Guidelines of Applicability Statements for
PPVPNs", draft-ietf-ppvpn-applicability-guidelines-00.txt, Work
in progress, Internet Draft, Jun 2002
This document expires on 8 August 2002.
INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02