Internet Engineering Task Force J. Sumimoto
INTERNET-DRAFT NTT
M. Carugi
Expires September 2002 France Telecom
(Co-editors)
J. De Clercq
Alcatel
A. Nagarajan
Sprint
M. Suzuki
NTT
March 1, 2002
Guidelines of Applicability Statements for PPVPNs
<draft-sumimoto-ppvpn-applicability-guidelines-02.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 is expected to be guidelines to assist development of
applicability statements for each PPVPN approach by providing a
check-list which consists of requirements/metrics. This check-list is
systematically composed of (i)requirements and metrics common to all
PPVPNs, (ii)requirements and metrics common to L3 PPVPN approaches,
(iii)requirements and metrics specific to L3 PE-based PPVPN
Sumimoto, et al. Expires September 2002 [Page 1]
INTERNET-DRAFT March 1, 2001
approaches, (iv)requirements and metrics specific to L3 CE-based
PPVPN approaches and (v)requirements and metrics common to L2 PPVPN
approaches, according to the classification of PPVPN approaches.
1. Summary for Sub-IP Area
1.1 Summary
This document is expected to be guidelines to assist development of
applicability statements of PPVPNs by providing a check-list which
consists of requirements/metrics. PPVPNs are classified into multiple
specific PPVPN approaches based on their characteristics. These PPVPN
approaches closely relate each other by sharing a portion of the
characteristics. Therefore, it is necessary to provide a check-list
for developing applicability statements of each PPVPN approach by
extracting requirements/metrics according to the mechanisms of PPVPN
approaches out of the service requirements of the requirements
documents. This document systematically provides such a check-list
along with the classification of PPVPN approaches.
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
The ppvpn charter clearly defines development of applicability
statements documents for PPVPN approaches as a working item of ppvpn
WG. Since this document is expected to assist these approach specific
applicability statements documents, ppvpn WG is appropriate as the
home of this document.
(*)We do not need justification as this document directly fits in ppvpn
WG.
2. Introduction
*** Goal and Role (This comment is to be deleted) ***
The term "PPVPNs"refers to Virtual Private Networks (VPNs) for which
the service provider participates in management and provisioning of
the VPN. PPVPNs can be classified into several PPVPN classes based on
their characteristics, and these PPVPN classes closely relate each
other by sharing some portion of the characteristics. Therefore, so
as to make approach-specific applicability statements significant, it
is necessary to systematically extract requirements/metrics directly
relating to protocols/mechanisms out of the service requirements
described in the requirements documents[PPVPN-REQ]. This document
Sumimoto, et al. Expires September 2002 [Page 2]
INTERNET-DRAFT March 1, 2001
provides a check-list which consists of the extracted
requirements/metrics. Each metric in the list is intended to clearly
point out what must be written in each approach specific
applicability statements documents, thus detailed description with
regard to the metric is out of scope of this document.
*** Scope and Organization (This comment is to be deleted) ***
PPVPN approaches for which applicability statements are to be
developed are,
- BGP MPLS VPNs[2547bis] and VR VPNs[VPN-VR, 2917bis] as L3
PE-based PPVPNs,
- IPsec VPNs[VPN-IPsec] as L3 CE-based PPVPNs,
- BGP signaled L2VPNs[], LDP signaled L2VPNs (with/without
Directory)[], RSVP signaled L2VPNs[] as L2 PE-based PPVPNs.
(To be updated)
Definition and classification of PPVPN approaches are overviewed in
Section 3. Section 4 provides list and outline of
requirements/metrics systematically according to the classification
of PPVPN approaches. Section 5 is for security considerations, and
section 6 is for references.
3. PPVPN technical overview
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 approach-specific applicability statements
documents. Detailed description is provided in the framework
document[PPVPN-FR].
PPVPNs can be classified into
- L3 PPVPNs / L2 PPVPNs
from the viewpoint of service layer for customers. On the other hand,
PPVPNs can be classified into
- PE based PPVPNs / CE-based PPVPNs
by the terminating point of VPN tunnels. Since these two keys of
classification are independent each other, four PPVPN classes are
defined after all. The rest of this section briefly overview each of
L3 PE-based VPNs, L3 CE-based VPNs, and L2 PE-based VPNs, out of the
four classes, which is covered by the following sections of this
document.
- Layer 3 PE-based VPNs
A layer 3 PE-based VPN is one in which PE devices in the SP network
provide the VPN-specific functions and SP forwards packets based on
layer 3 information. BGP MPLS and VR approach are included in this
class.
Sumimoto, et al. Expires September 2002 [Page 3]
INTERNET-DRAFT March 1, 2001
- Layer 3 CE-based VPNs
In CE-based VPNs, the VPN-specific functions (e.g. tunneling) are
deployed in the CE devices, while the provider network has no VPN
awareness on the data-plane level. SP forwards packets based on
layer 3 information. IPsec VPN is included in this class.
- Layer 2 PE-based VPNs
A layer 2 PE-based VPN is one in which PE devices in the SP network
provide the VPN-specific functions and SP forwards packets based on
layer 2 information. BGP signaled L2VPNs, LDP signaled L2VPNs
(with/without Directory), and RSVP signaled L2VPNs are included in
this class.
4. List and outline of requirements and metrics for evaluating each
PPVPN approach
This section provides list and outline of requirements/metrics common
to all PPVPNs (in Section 4.1), common to L3 PPVPN approaches (in
Section 4.2), specific to L3 PE-based PPVPN approaches (in Section
4.3), specific to L3 CE-based PPVPN approaches (in Section 4.4) and
common to L2 PE-based PPVPN approaches (in Section 4.5), according to
the classification of PPVPN approaches. Note that
requirements/metrics for a higher PPVPN class must apply to any
inheriting lower PPVPN classes (maybe concurrently, if multiple lower
PPVPN classes provisioned in an SP network concurrently). For
example, VR approach must be checked not only by requirements/metrics
for specific to L3 PE-based PPVPN approaches but also by
requirements/metrics common to all PPVPNs and common to L3 PPVPN
approaches. In this section, AS stands for Applicability Statements.
4.1 Requirements and metrics common to all PPVPNs
4.1.1 Isolated exchange of routing and data information
Each specific AS document must clarify whether and how the following
attributes are implemented by the concerned PPVPN approach.
- Isolated data forwarding (mandatory)
- Isolated routing (i.e. constrained distribution of reachability
to only VPN sites)
(internal topology of VPN should not be visible to the shared
public network (Internet))
4.1.2 Overlapping customer address space
Each specific AS document must clarify whether and how the following
Sumimoto, et al. Expires September 2002 [Page 4]
INTERNET-DRAFT March 1, 2001
attributes are implemented by the concerned PPVPN approach.
- Support of non-unique customer addresses
- Support of private addresses
Each specific AS document must also clarify constraints, if any.
- Constraint
4.1.3 Management (To be updated: More detailed metrics required!)
4.1.3.1 Configuration/Provisioning
4.1.3.2 Monitoring
4.1.3.3 Customer Management
4.1.3.4 SLA Monitoring
4.1.3.5 Security
4.1.4 migration impacts
Each specific AS document must clarify
- Functions required to be added from the customers'/providers'
point of view.
4.2 Requirements and metrics common to L3 PPVPN approaches
4.2.1 Security
Each specific AS document must clarify whether and how the following
attributes are supported by the concerned PPVPN approach.
- Confidentiality
- Integrity
- Authentication
- Replay attack prevention
4.2.2 Tunneling
Each specific AS document must clarify the following attributes.
- Kind of supported tunneling techniques
- Tunnel termination points
4.2.3 QoS
Sumimoto, et al. Expires September 2002 [Page 5]
INTERNET-DRAFT March 1, 2001
Each specific AS document must clarify (1)whether supported or not,
(2)which link/path/tunnel to be applied (CE-CE, PE-PE, etc.), (3)what
kind of services/classes, (4)how to support/operate, for each of the
following by the concerned PPVPN approach.
- Intserv/RSVP,
- Diffserv,
- Point to point (if any),
- Point to cloud (if any).
4.2.4 Scalability
With regard to each of the folloing factors, each specific AS
document must clarify (1)what resource is pressed by the factor (e.g.
VFI's table size) and (2)how (in what order) the resource is pressed
(e.g. O(n) or O(n^2) or ...).
- Number of tunnels/VPN sessions,
- Impact of addition of new site
4.3 Requirements and metrics specific to L3 PE-based PPVPN approaches
4.3.1 Scalability
With regard to each of the folloing factors, each specific AS
document must clarify (1)what resource is pressed by the factor (e.g.
VFI's table size) and (2)how (in what order) is the resource pressed?
(e.g. O(n) or O(n^2) or ...).
- Number of VPNs,
(Especially, influence toward VFI's table size / number of tunnels
should be considered.)
- Number of sites,
(Especially, influence toward VFI's table size / number of tunnels
should be considered.)
- Number of VRFs/VRs and interfaces per VPN,
(Especially, influence toward processing overhead of a PE should
be considered.)
- Number of tunnels,
- Number of routes per VPN,
- Rate of configuration changes / impact of adding new site,
(Especially, influence toward increase of controling traffic /
average convergence time should be considered.)
- Statefulness of mechanisms used,
- Impact on routing protocols,
- Performance impacts,
4.3.2 Core network requirements
Sumimoto, et al. Expires September 2002 [Page 6]
INTERNET-DRAFT March 1, 2001
Each specific AS document must clarify the following attributes of
concerned PPVPN approach.
- Routing protocol requirements, (To be more specific?)
- Core router awareness of mechanisms used
4.3.3 Addressing
Each specific AS document must clarify the following attributes of
concerned PPVPN approach.
- Private addressing (rfc 19l8) support
4.3.4 Management (To be updated: More detailed metrics required!))
4.1.3.1 Configuration/Provisioning
4.1.3.2 Monitoring
4.1.3.3 Customer Management
4.1.3.4 Security -- Should this be here or covered above?
4.3.5 QoS and SLAs (To be updated)
4.3.5.1 SLA Monitoring
4.3.6 Auto-discovery
Each specific AS document must clarify
- Whether any mechanism are supported or not.
If supported, it must also clarify the following attributes.
- Kind of mechanism,
- What is discovered by the mechanism,
- Information exchanged by the mechanism
4.4 Requirements and metrics specific to L3 CE-based PPVPN approaches
(To be updated)
4.4.1 Scalability - similar to 4.3, also need to address scalability
of key distribution system, impacts on performance due to encryption
mechanisms
4.4.2 Access network requirements (may overlap with other sections,
need suggestions on how to organize this)(access types supported,
Sumimoto, et al. Expires September 2002 [Page 7]
INTERNET-DRAFT March 1, 2001
access qos support, access security support
4.4.3 Management (To be updated: More detailed metrics required!)
There should be a few subsections here:
4.1.3.1 Configuration/Provisioning
4.1.3.2 Monitoring
4.1.3.3 Customer Management
4.1.3.4 SLA Monitoring
4.1.3.5 Security
4.4.4 QoS (To be filled out.)
4.5 Requirements and metrics common to L2 PE-based PPVPN approaches
(To be checked later.)
4.5.1 Layer 3 independence
Each specific AS document must clarify the following point.
- L3 protocol; IP only or not
4.5.2 Auto-discovery
Each specific AS document must clarify
- Whether any mechanism are supported or not.
If supported, it must also clarify the following attributes.
- Kind of mechanism
- What is discovered by the mechanism
- Information exchanged by the mechanism
4.5.3 Scalability
With regard to each of the folloing factors, each specific AS
document must clarify (1)what resource is pressed by the factor (e.g.
VFI's table size) and (2)how (in what order) the resource is pressed
(e.g. O(n) or O(n^2) or ...).
- Number of VPNs,
(Especially, influence toward VSI's table size / number of tunnels
Sumimoto, et al. Expires September 2002 [Page 8]
INTERNET-DRAFT March 1, 2001
should be considered.)
- Number of sites,
(Especially, influence toward VSI's table size / number of tunnels
should be considered.)
- Number of VSIs and interfaces per VPN,
(Especially, influence toward processing overhead of a PE should
be considered.)
- Rate of configuration changes / impact of adding new site,
(Especially, influence toward increase of controling traffic /
average convergence time should be considered.)
4.5.4 Management (To be filled out.)
4.5.5 Multicast (Needed?)
Other key reqs??
5. Security considerations (To be filled out.)
6. Acknowledgments
The authors of this document would like to acknowledge the
suggestions and comments received from the entire Layer 3
Applicability Statement Design Team formed in the ppvpn WG. Besides
the authors, the members of the design team include Luyuan Fang, Paul
Knight, Dave McDysan, Thomas Nadeau, Olivier Paridaens, Yakov
Rekhter, Eric Rosen, Chandru Sargor, Benson Schliesser, Cliff Wang
and Rick Wilder.
7. 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.
[VPN-IPsec] De Clercq, J. et al., "A Framework for Provider
Provisioned CE-based Virtual Private Networks using IPsec," work
in progress.
Sumimoto, et al. Expires September 2002 [Page 9]
INTERNET-DRAFT March 1, 2001
(*) Additional references to be provided here.
8. Authors' address
Junichi Sumimoto (Co-editor)
NTT Information Sharing Platform Labs.
3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Japan
Email: sumimoto.junichi@lab.ntt.co.jp
Marco Carugi (Co-editor)
France Telecom Research and Development
Technopole Anticipa -- 2, av. Pierre Marzin
22307 Lannion cedex, France
Phone : + 33 2 96 05 36 17
Email : marco.carugi@francetelecom.com
Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
Email: jeremy.de_clercq@alcatel.be
Ananth Nagarajan
Sprint
9300 Metcalf Ave,
Overland Park, KS 66212, USA
Email: ananth.nagarajan@mail.sprint.com
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
Sumimoto, et al. Expires September 2002 [Page 10]