Internet Engineering Task Force J. Sumimoto
INTERNET-DRAFT M. Suzuki
NTT
Expires May 20, 2002
M. Carugi
France Telecom
J. De Clercq
Alcatel
C. Y. Lee
Paragon Networks
November 21, 2001
Guidelines of Applicability Statements for PPVPNs
<draft-sumimoto-ppvpn-applicability-guidelines-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.
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.
Abstract
This document provides guidelines of applicability statements for
Provider Provisioned Virtual Private Networks (PPVPNs). The document
is intended as guidelines to assist in the development of
applicability statements for each specific PPVPN solution.
# Current version focuses on layer 3 PPVPNs. Other stuff should be
Sumimoto Expires May 2002 [Page 1]
INTERNET-DRAFT November 21, 2001
filled out in future.
1. Summary for Sub-IP Area
1.1 Summary
This document provides guidelines of applicability statements for
Provider Provisioned Virtual Private Networks (PPVPNs). The document
is intended as guidelines to assist in the development of
applicability statements for each specific PPVPN approach.
1.2 Where does it fit in the Picture of the Sub-IP Work
This document fits in ppvpn WG.
1.3 Why is it Targeted at this WG
As this document describes the contents for the following work item
from the ppvpn WG charter:
"An applicability statement will be developed for each approach that
describes the environments in which the approaches are suitable for
deployment, including analysis of scaling impact of the approach on
SPs and threat analysis. "
This document is intended as guidelines to assist in the development
of applicability statement documents for each specific PPVPN
approach.
(*)We do not need justification as this document directly
fits in ppvpn WG.
2. Introduction (*** Objective and Scope ***)
*** What is this document? ***
This document is intended as guidelines to assist in the development
of applicability statement documents for each specific PPVPN
approach. Towards this end, it provides a high level discussion of
the applicability and limitations of PPVPNs and identifies a list of
PPVPN requirements. Individual applicability statements may associate
the applicability and limitations of the specific approach with this
list of requirements. In this respect, this document may also help
providers and users to define the applicability scenarios of each
PPVPN approach and to position it against a set of requirements.
*** Terminology (PPVPN, Layer 3/Layer2 VPNs, CE-based VPNs)***
Sumimoto Expires May 2002 [Page 2]
INTERNET-DRAFT November 21, 2001
The term "PPVPNs" refers to Virtual Private Networks (VPNs) for which
the service provider participates in management and provisioning of
the VPN, and there are multiple different types of PPVPNs. One
distinction between the various types of VPNs considered in this
document, is the distinction between PE-based VPNs and CE-based VPNs.
Furthermore, from the customer's layer viewpoint, PE-based VPNs are
classified into two categories, layer 3 and 2 PE-based VPNs. Multiple
technical approaches are possible in these categories (e.g., BGP MPLS
VPNs as defined in [2547bis], VR VPNs as defined in [VPN-VR] or
[2917bis] are approaches included in layer 3 VPNs). This document
provides a description of these individual approaches in Section 3.
For more detail on definitions of all technical terms mentioned in
this paragraph, see [VPN-FR].
*** Scope and organization of this draft, and scope expected in
each individual AS draft ***
Section 3 provides technical overview of each PPVPN approach to
facilitate understanding of applicability and limitations content.
Section 4 outlines requirements for PPVPNs as a basic list for
discussing applicability and limitations. The same list may be used
for individual AS documents to be developed in future. Section 5
presents applicability of PPVPNs and Section 6 presents limitations
of PPVPNs. Section 7 is for security considerations, section 8 for
references. This document focuses on discussion common to all
approaches, however, it may play an introductory role toward
individual AS documents to be developed in future. Detailed
applicability and limitations sections are expected to be developed
in these individual AS documents.
3. PPVPN technical overview
*** Brief overview of PPVPN types ***
This section provides a brief overview on the various types of PPVPNs
as an introductory guidance toward discussions in the rest of this
document and in developing individual AS documents. Individual
approach-specific AS documents are expected to include more detailed
technical overview of the respective approach.
Note that as some of the engineering tradeoffs between different
types of PPVPNs are important, this document will discuss them in a
further version.
PE-based VPNs means VPNs whose VPN-specific functions are deployed by
the SP in the provider edge devices, while the customer equipment has
no VPN awareness. PE-based VPNs may be distinguished by the service
layer offered.
Sumimoto Expires May 2002 [Page 3]
INTERNET-DRAFT November 21, 2001
- Layer 3 PE-based VPNs
In a layer 3 PE-based 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 data link layer and the IP layer
across the access network. The PE performs forwarding of user data
packets based on information in the IP layer header, such as an
IPv4 or IPv6 destination address. The CE sees the PE as a layer 3
device such as an IPv4 or IPv6 router.
- Layer 2 PE-based VPNs
In a layer 2 PE-based VPN service, a CE receives data link layer
(i.e., layer 2) service from the SP. The CE and PE are adjacent to
each other at the data link layer and not at the IP layer across
the access network. A PE performs forwarding of user data packets
based on information in the packets' data link 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.
Both layer 3 and 2 PE-based VPNs include various technical
approaches. Specific approaches of layer 3 PE-based VPNs include BGP
MPLS VPNs as defined in [2547bis], virtual routers (VRs) as defined
in [VPN-VR] or [2917bis]. Specific approaches of layer 2 PE-based
VPNs include 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). All
types of PPVPNs adopt some tunneling mechanisms in SP networks based
on IP (for example, MPLS, L2TP, GRE and IPsec) and service providers
participate in management and provisioning of the PPVPNs. The
tunneling mechanisms considered for layer 2 PPVPNs are those
specified in the charter of the pwe3 working group i.e., MPLS, GRE
and L2TP. This is part of the requirements mentioned in the following
section.
This document also provides brief overview of CE-based VPNs here, for
mentioning requirements specific to CE-based VPNs below.
- CE-based VPNs
In CE-based VPNs, the VPN-specific functions (e.g. tunneling) are
deployed in the customer edge devices, while the provider network
has no VPN awareness on the data-plane level. For provider
provisioned CE-based VPNs, the VPN functions on the CE device are
managed by the service provider [VPN-FR].
Sumimoto Expires May 2002 [Page 4]
INTERNET-DRAFT November 21, 2001
With CE-based VPNs, the VPN tunnels are IP tunnels (IPsec, L2TP,
GRE, etc.) originated at the CE devices. The PE device will forward
the customer's IP packets based on the encapsulating (outer) IP
header. As such, the PE device and the CE device have a peering
relationship at the IP level, but the PE device has no VPN
knowledge.
4. Outline of requirements for PPVPNs
*** Why and how does this document outline requirements? ***
This section briefly outlines main requirements for PPVPNs provided
in [VPN-REQ] as a basic list for discussing applicability and
limitations in the following sections. Detailed requirements are out
of the scope of this document, because these are fully presented in
[VPN-REQ]. This section classifies the requirements into 3
categories, general requirements (for both layer 3/layer 2 PE-based
VPNs and CE-based VPNs), requirements specifically for PE-based layer
3 VPNs, and requirements specifically for layer 2 PE-based VPNs and
requirements specifically for CE-based VPNs. Above distinction is
just a suggestion to be discussed. The point we want to raise here is
that we should classify requirements according to the most
appropriate way to develop individual AS documents. Apart from
customer/service provider requirement distinction, a more extended
classification could be :
- general requirements,
- service-specific requirements (L3 PE-based, L2 PE-based,
CE-based, etc.), basically following current framework/req ID
taxonomy
- solution-specific requirements, or approach-specific
requirements
(we may have in theory more than one solution per each approach)
*** Concrete list of the requirements: 4.1 - 4.4 ***
4.1 General requirements
4.1.1 Security (including threat analysis as mentioned in charter)
Each PPVPN solution should support a range of security related
features. Basic levels of security service, like traffic
isolation, should be supported. Enhanced levels of security
services, like edge-to-edge encryption, authentication, or replay
attack prevention should be supported if some customers require
them. Furthermore, firewall functionality may be desired when
Internet access is provided.
4.1.2 QoS and SLA support
Sumimoto Expires May 2002 [Page 5]
INTERNET-DRAFT November 21, 2001
With regards to QoS support, a PPVPN shall be able to support QoS
in one or more of the following standard modes:
- Best Effort (support mandatory for all PPVPN types)
- QoS support (e.g., Intserv) by RSVP, TE by RSVP extension or
CR-LDP
- Diffserv marked
- Across packet-switched access networks
4.1.3 Manageability (including ease of monitoring/accounting)
An SP and its customers must be able to manage the capabilities and
characteristics of their VPN services. To the greatest possible
extent, automated operations and interoperability with standard
management platforms should be supported.
4.1.4 Interoperability
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 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.
4.1.5 Scalability (convergence time, routing tables, VPN size,
routing instances, etc)
Routing updates in VPNs shall not affect the stability of the SP
network. Applicability and limitations in relation with parameters
provided in 5.1.1 [PPVPN-REQ] should be provided. (See 5.1.2
[PPVPN-REQ] for solution-specific metrics)
4.1.6 Migration impact
A range of scenarios of customer migration must be supported. Full
migration of all sites must be supported. Support for cases of
partial migration is highly desirable [Y.1311.1], that is, legacy
private network sites that belong to the PPVPN service should still
have L2 connectivity or L3 reachability to the sites that migrate
to the PPVPN service.
4.1.7 Learning VPN Related Information
Configuration of CE and PE devices is a significant task for a
Sumimoto Expires May 2002 [Page 6]
INTERNET-DRAFT November 21, 2001
service provider. Solutions should strive to contain methods that
dynamically allow VPN information to be learned by relevant PEs
and/or CEs to reduce configuration complexity.
4.1.8 Reliability (Including Protection/Restoration)
The Service provider should be able to deploy protection and
restoration mechanisms within the service provider's backbone
infrastructure to increase reliability and fault tolerance of the
VPN service offering. These techniques should be scalable.
Therefore, implementation of such function in the backbone on a
per-VPN basis may be prohibited.
4.1.9 Network environment
Functions required to PEs:
Some PPVPN types or approaches require special functions to PEs.
The less such special functions are, the easier to deploy.
(To be completed.)
4.1.10 Support of various service scenarios (inter-AS, wholesale,
Internet access, extranet, etc.)
(To be filled out.)
4.1.11 Support of various connectivity scenarios (access network
connectivity, etc.)
(To be filled out.)
4.1.12 Topology
A PPVPN should support arbitrary, customer agent defined inter-site
connectivity, ranging, for example, from hub-and-spoke, partial
mesh to full mesh topology.
4.1.13 Operation/Deployment considerations (including adding/moving
sites)
Ease of Operation/Deployment is highly desired. Special skill for
operation/deployment may be an obstacle.
(To be completed.)
4.1.14 Routing protocol and policy routing support
There should be no restriction on the routing protocols used
between CE and PE devices or between CE devices. At least the
following protocols must be supported: static routing, IGP, such as
Sumimoto Expires May 2002 [Page 7]
INTERNET-DRAFT November 21, 2001
RIP, OSPF, IS-IS, or BGP.
(To be completed.)
4.1.15 Cost considerations
(To be filled out.)
4.2 Requirements specifically for Layer 3 PE-based VPNs
4.2.1 Addressing
The following supports from PPVPN solutions are required:
o globally unique/private IP addresses, IPv4/IPv6, for both
unicast and multicast
o obtained by the customer from IANA / statically assigned by
the PPVPN service provider
o on-demand, dynamically assigned IP addresses (e.g., DHCP),
irrespective of whether the access is temporary (e.g.,
remote) or permanent (i.e., dedicated)
Customer VPN address overlapping shall be supported - IP addresses
have to be unique only within a given VPN, but not across VPNs. In
the case where private IP addresses are used, a PPVPN solution must
provide a means for an SP to translate such addresses to public IP
addresses for communication with other VPNs using overlapping
addresses, or the Internet.
4.2.2 Interworking with other solutions
Service interworking among different solutions providing PPVPN
services is highly desirable and should be supported in a scalable
manner as much as possible.
4.2.3 Provisioning Value-Added Service Access
(To be filled out.)
4.3 Requirements specifically for Layer 2 PE-based VPNs
(Requirements from the following references are to be outlined
here;
draft-ietf-ppvpn-l2vpn-00.txt
draft-tsenevir-l2-req-01.txt,
draft-ouldbrahim-ethernet-l2vpn-requirements-00.txt,
draft-ouldbrahim-l2vpn-lpe-00.txt,
draft-heron-ppvpn-vpsn-reqmts-00.txt,
draft-kb-ppvpn-l2vpn-motiv-00.txt,
Sumimoto Expires May 2002 [Page 8]
INTERNET-DRAFT November 21, 2001
draft-kompella-ppvpn-l2vpn-00.txt,
draft-rosen-ppvpn-l2-signaling-00.txt,
draft-heinanen-dirldp-eth-vpns-01.txt.)
4.4 Requirements specifically for CE-based VPNs
4.4.1 Addressing
Same requirements as in section in 4.2.1.
4.4.2 Support for dynamic routing
Independently of the used tunneling mechanism and the way the VPN
tunnels are established, a CE-based VPN solution should support for
the dynamic distribution of routing information between different
sites of the same VPN. The relationship between routing
information, VPN membership and VPN tunnel status should always be
consistent.
4.4.3 SP's management system requirements
As the SP will configure the VPN functions on the customer's CE
devices, the 'provisioning mechanism' that is used plays an
important role. Different options are available for this
provisioning: manual configuration, the use of a management
protocol (e.g. SNMP, COPS, etc.), of a directory access protocol
(e.g. LDAP), etc. Important requirements with regards to this
provisioning scheme are:
- the scalability (as a single SP may need to provision a
large amount of CE devices from a large number of VPNs)
- the security aspects with regards to authentication,
privacy etc. (as the security of the VPN management affects
the complete security of the VPN itself).
5. Applicability
*** Applicability description of identified solutions ***
5.1 Security
All of PPVPN approaches (BGP-VPNs, VR, port-based VPNs) achieve
logical traffic isolation by adopting VPN tunnels operated by
service providers. All of PE-based VPN solutions prohibit an end
user from IP masquerade or mis-delivering toward unauthorized VPNs,
as a PE identifies correspondence between L2 interfaces toward CEs
Sumimoto Expires May 2002 [Page 9]
INTERNET-DRAFT November 21, 2001
and VPNs. All of CE-based VPN solutions achieve logical traffic
isolation by adoption direct VPN tunnels between CE devices. It
follows that all of PPVPN solutions achieve the same security level
as VPNs implemented by TDM or packet network. For more discussion
regarding stronger security, see the limitation section.
5.2 QoS support/SLA support
- Best effort
Any IP packet delivery of both BGP MPLS and VR approach by using
any tunneling technology (MPLS, IPsec, or GRE) without optional QoS
support mechanisms is best effort.
- QoS support (e.g., Intserv by RSVP, TE by RSVP extension or CR-
LDP)
Any [current] individual approach documents do not specify how they
support QoS by RSVP [extension] or CR-LDP. If an individual
approach can support it, the corresponding approach-specific AS
document should clarify its applicability and limitations from the
viewpoint of interval, kind of services, and how to operate.
- Diffserv
If an individual approach can support it, the corresponding
approach-specific AS document should clarify its applicability and
limitations from the viewpoint of interval, kind of services, and
how to operate. ('A Core MPLS IP VPN Architecture' [2917bis]
refers to a method to support diffserv by using private LSPs per
VPN. Other [current] individual approach documents do not specify
how they support diffserv.)
Furthermore, method for tunnels to carry DSCP information must be
clarified, since it depends on which tunneling technology is used
and this document should make sure of them. Current situation of
such clarification is as follows;
MPLS -- Work in progress [MPLS-DIFF].
IPsec, IP in IP -- [RFC2983] gives two conceptual models for the
interaction of diffserv with IP tunnels and relevant
considerations.
GRE -- There is no field to carry DSCP information in GRE header.
Moreover, there is no specification of how to treat fields for
DSCP between an outer IP header and an inner IP header in case
that GRE is applied for IP encapsulation within IP.
Sumimoto Expires May 2002 [Page 10]
INTERNET-DRAFT November 21, 2001
5.3 Manageability
Defining MIBs for BGP MPLS VPNs approach are on progress. VR
approach- specific MIBs are on progress. MIBs for the port-based
VPN approaches are not currently defined (some work in pwe3 WG may
be used for that). A MIB for the PP CE-based approach is not
currently defined. Detailed descriptions are expected to be
included in each AS document per technical solution.
5.4 Interoperability
Each approach-specific AS document must clarify applicability and
limitation in terms of interoperability within each technical
solution belonging the approach.
5.5 Scalability
See the limitations Section.
5.6 Migration impact
Most important point here is whether any CE can access a PE in the
same manner as it accesses VPNs based on leased lines. As VR
approach makes use of standard routing protocols without any
extensions, any CE of VR approach can access a PE in the same
manner as it accesses VPNs based on leased lines. With regard to
BGP MPLS approach, any CE can access a PE in the same manner as it
accesses VPNs based on leased lines if the CE does not directly
participate in BGP MPLS control. However, as is well known , any CE
is required extended BGP capability if the CE directly participates
in BGP MPLS control.
See the limitation section.
5.7 Learning VPN Related Information
This item specifically provides whether each approach can supports
auto-discovery mechanisms. Detail should be described in each
approach-specific AS document. If some constraints exist, they
should be clarified in the limitations section. Both VR and BGP
MPLS approach can support membership discovery mechanism.
See the same item in the limitations Section.
5.8 Reliability
If some restoration/recovery mechanisms are built in tunneling
technologies, they are useful to enhance reliability of PPVPNs. If
such built-in mechanism is not available, route duplication may be
used for enhancing reliability of PPVPNs.
Sumimoto Expires May 2002 [Page 11]
INTERNET-DRAFT November 21, 2001
5.9 Network environment
Each approach-specific AS document must clarify special
requirements on network environment for using the approach. Some
examples are given here. Though VR approach requires that PE
devices implement VR functions, it does not always require
implementation of any extension of standard routing protocols. BGP
MPLS approach requires that PE devices implement not only VRF
functions but also extended BGP and semantics specified in
[2547bis].
Note that PE devices of BGP MPLS approach are required MPLS
functions even in case that VPN tunnels are supported by IPsec or
GRE (i.e., other than MPLS) within SP networks.
5.10 Support of various service scenarios (inter-AS, wholesale,
Internet access, extranet, etc.)
(To be filled out.)
5.11 Support of various connectivity scenarios (access network
connectivity, etc.)
(To be filled out.)
5.12 Topology
As applicability of topology depends on each technical solution,
each AS document for specific technical solution is expected to
describe this issue for the solution.
5.13 Operation/Deployment considerations (Includes adding/moving
sites)
(To be filled out.)
5.14 Routing protocol and policy routing support
(To be filled out.)
5.15 Cost considerations
(To be filled out.)
5.16 Addressing
(To be filled out.)
5.17 Interworking with other solutions
Sumimoto Expires May 2002 [Page 12]
INTERNET-DRAFT November 21, 2001
Applicability of layer 3 PPVPN interworking is described here,
based on the interworking interface section of [PPVPN-FR]. Static
interworking on data plane without auto-discovery nor management
has been made available between VR approach and BGP MPLS approach.
See limitations Section for a limitation related auto-discovery and
management.
5.18 Provisioning Value-Added Service Access
(To be filled out.)
6. Limitations
*** Description of general limitations of identified solutions ***
6.1 Security
Not all PPVPN solutions support confidentiality, integrity,
authentication, and replay attack prevention. To achieve them,
IPsec (or other encryption mechanism) must be used as tunneling
mechanism or used over VPN tunnels. Even with the use of IPsec, the
security level offered is dependent on the scope of the IPsec
security: encrypting on a CE-to-CE basis (as in CE-based VPNs) will
offer a higher level of protection than encrypting on a PE-to-PE
basis (as in PE-based VPNs).
Note that some configuration error can cause traffic isolation to
be broken.
6.2 Scalability
(To be filled out.)
6.3 Learning VPN Related Information
BGP MPLS approach is bound to specific membership discovery
mechanism using extended BGP and semantics specified in [2547bis].
6.4 Operation/Deployment considerations (including adding/moving
sites)
(To be filled out.)
6.5 Addressing
In case that a site belongs to multiple PPVPNs, they cannot have
duplicated IP addresses.
(To be completed.)
Sumimoto Expires May 2002 [Page 13]
INTERNET-DRAFT November 21, 2001
6.6 Interoperability
Each approach-specific AS document must clarify limitations in
terms of interoperability within each technical solution belonging
the approach.
6.7 Interworking with other solutions
Auto-discovery and management scheme beyond interworking interface
is not clear at present.
(*)Other items have to be added.
7. Security considerations
(To be written.)
8. References
[PPVPN-FR] Callon, R. et al., "A Framework for Provider Provisioned
Virtual Private Networks," work in progress.
[PPVPN-REQ] Carugi, M. et al., "Service Requirements for Provider
Provisioned Virtual Private Networks," work in progress.
[2547bis] Rosen E. et al., "BGP/MPLS VPNs," work in progress.
[VPN-VR] Ould-Brahim, H. et al., "Network based IP VPN Architecture
using Virtual Routers, " work in progress.
[2917bis] Muthukrishnan, K. et al., "A Core MPLS IP VPN Architecture,
" work in progress.
[MPLS-DIFF] Le Faucheur, F. et al., "MPLS Support of Differentiated
Services, " work in progress.
[RFC2983] Black, D., "Differentiated Services and Tunnels," RFC2983,
October 2000.
(*) Additional references to be provided here.
Sumimoto Expires May 2002 [Page 14]
INTERNET-DRAFT November 21, 2001
9. Authors' address
Junichi Sumimoto
NTT Information Sharing Platform Labs.
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Email: sumimoto.junichi@lab.ntt.co.jp
Muneyoshi Suzuki
NTT Information Sharing Platform Labs.
3-9-11, Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
Email: suzuki.muneyoshi@lab.ntt.co.jp
Marco Carugi
France Telecom Research and Development
Technopole Anticipa -- 2, av. Pierre Marzin
22307 Lannion cedex, France
Phone : + 33 2 96 05 36 17
Email : marco.carugi@francetelecom.com
Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: jeremy.de_clercq@alcatel.be
Cheng-Yin Lee
Paragon Networks
leecy@paragon-networks.com
Sumimoto Expires May 2002 [Page 15]