< draft-ietf-l3vpn-generic-reqts-02.txt   draft-ietf-l3vpn-generic-reqts-03.txt >
Internet Draft Ananth Nagarajan Internet Draft Ananth Nagarajan
Expiration Date: July 2004 Juniper Networks Expiration Date: August 2004 Juniper Networks
Category: Informational (Editor) Category: Informational (Editor)
January 2004 February 2004
Generic Requirements for Provider Provisioned Virtual Generic Requirements for Provider Provisioned Virtual
Private Networks Private Networks
<draft-ietf-l3vpn-generic-reqts-02.txt> <draft-ietf-l3vpn-generic-reqts-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC-2026]. provisions of Section 10 of [RFC-2026].
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. Internet- may also distribute working documents as Internet-Drafts. Internet-
Drafts are draft documents valid for a maximum of six months and may be Drafts are draft documents valid for a maximum of six months and may be
skipping to change at page 1, line 44 skipping to change at page 2, line 4
Virtual Private Networks (PPVPN). The requirements are categorized into Virtual Private Networks (PPVPN). The requirements are categorized into
service requirements, provider requirements and engineering service requirements, provider requirements and engineering
requirements. These requirements are not specific to any particular requirements. These requirements are not specific to any particular
type of PPVPN technology, but rather apply to all PPVPN technologies. type of PPVPN technology, but rather apply to all PPVPN technologies.
All PPVPN technologies are expected to meet the umbrella set of All PPVPN technologies are expected to meet the umbrella set of
requirements described in this document. requirements described in this document.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in [RFC-2119].
Table of Contents Table of Contents
1. Introduction .................................... 3 1. Introduction .................................... 3
1.1. Problem Statement ............................... 3 1.1. Problem Statement ............................... 3
1.2. Deployment Scenarios ............................ 4 1.2. Deployment Scenarios ............................ 4
1.3. Outline of this document ........................ 5 1.3. Outline of this document ........................ 5
2. Contributing Authors ............................ 6 2. Contributing Authors ............................ 6
3. Definitions and Taxonomy ........................ 7 3. Definitions and Taxonomy ........................ 7
skipping to change at page 3, line 10 skipping to change at page 3, line 12
8.1. Normative References ............................ 25 8.1. Normative References ............................ 25
8.2. Informative References .......................... 25 8.2. Informative References .......................... 25
9. Acknowledgements ................................ 26 9. Acknowledgements ................................ 26
10. Editor's Address ................................ 26 10. Editor's Address ................................ 26
11. Full Copyright Statement ........................ 26 11. Full Copyright Statement ........................ 26
1. Introduction 1. Introduction
This document is an output of the design team formed to develop This document is an output of the design team formed to develop
requirements for PPVPNs in the Provider Provisioned Virtual Private requirements for PPVPNs in the Provider Provisioned Virtual Private
Networks (PPVPN) working group. With the split of the PPVPN working Networks (PPVPN) working group and provides requirements that are
group into Layer 2 (L2VPN) and Layer 3 (L3VPN) working groups, this generic to both Layer 2 Virtual Private Networks (L2VPN) and Layer 3
work fits within the scope of the L2VPN and L3VPN working groups, and Virtual Private Networks (L3VPN). This document discusses generic
is being progressed in the L3VPN working group. This document PPVPN requirements categorized as service, provider and engineering
discusses generic PPVPN requirements categorized as service, provider requirements. These are independent of any particular type of PPVPN
and engineering requirements. These are independent of any technology. In other words, all PPVPN technologies are expected to
particular type of PPVPN technology. In other words, all PPVPN meet the umbrella set of requirements described in this document.
technologies are expected to meet the umbrella set of requirements PPVPNs may be constructed across single or multiple provider networks
described in this document. PPVPNs may be constructed across single and/or Autonomous Systems (ASes). In most cases the generic
or multiple provider networks and/or Autonomous Systems (ASes). In requirements described in this document are independent of the
most cases the generic requirements described in this document are deployment scenario. However, specific requirements that differ based
independent of the deployment scenario. However, specific on whether the PPVPN is deployed across single or multiple providers
requirements that differ based on whether the PPVPN is deployed (and/or ASes) will be pointed out in the document. Specific
across single or multiple providers (and/or ASes) will be pointed out requirements related to Layer 3 PPVPNs are described in [L3REQTS].
in the document. Specific requirements related to Layer 3 PPVPNs are Similarly, requirements that are specific to layer 2 PPVPNs are
described in [L3REQTS]. Similarly, requirements that are specific to described in [L2REQTS].
layer 2 PPVPNs are described in [L2REQTS].
1.1. Problem Statement 1.1. Problem Statement
Corporations and other organizations have become increasingly Corporations and other organizations have become increasingly
dependent on their networks for telecommunications and data dependent on their networks for telecommunications and data
communication. The data communication networks were originally built communication. The data communication networks were originally built
as Local Area Networks (LAN). Over time the possibility to as Local Area Networks (LAN). Over time the possibility to
interconnect the networks on different sites has become more and more interconnect the networks on different sites has become more and more
important. The connectivity for corporate networks has been supplied important. The connectivity for corporate networks has been supplied
by service providers, mainly as Frame Relay (FR) or Asynchronous by service providers, mainly as Frame Relay (FR) or Asynchronous
skipping to change at page 4, line 16 skipping to change at page 4, line 17
different customers, mechanisms such as Layer 2 connections or Layer different customers, mechanisms such as Layer 2 connections or Layer
2/3 tunnels are necessary. When the shared infrastructure is an IP 2/3 tunnels are necessary. When the shared infrastructure is an IP
network, the tunneling technologies that are typically used are network, the tunneling technologies that are typically used are
IPsec, MPLS, L2TP, GRE, IP-in-IP etc. IPsec, MPLS, L2TP, GRE, IP-in-IP etc.
Traditional Internet VPNs have been based on IPsec to provide Traditional Internet VPNs have been based on IPsec to provide
security over the Internet. Service providers are now beginning to security over the Internet. Service providers are now beginning to
deploy enhanced VPN services that provide features such as service deploy enhanced VPN services that provide features such as service
differentiation, traffic management, Layer 2 and Layer 3 differentiation, traffic management, Layer 2 and Layer 3
connectivity, etc. in addition to security. Newer tunneling connectivity, etc. in addition to security. Newer tunneling
mechanisms have certain features that allow the service providers to mechanisms have certain features that allow the service providers to
provide these enhanced VPN services. provide these enhanced VPN services.
The VPN solutions we define now must be able to accommodate the The VPN solutions we define now MUST be able to accommodate the
traditional types of VPNs as well as the enhanced services now being 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 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 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. In doing so the VPNs SHOULD NOT be allowed to violate basic
Internet design principles or overload the Internet core routers or Internet design principles or overload the Internet core routers or
accelerate the growths of the Internet routing tables. Specifically, accelerate the growths of the Internet routing tables. Specifically,
Internet core routers shall not be required to maintain VPN-related Internet core routers SHALL NOT be required to maintain VPN-related
information, regardless of whether the Internet routing protocols are information, regardless of whether the Internet routing protocols are
used to distribute this information or not. In order to achieve this, used to distribute this information or not. In order to achieve this,
the mechanisms used to develop various PPVPN solutions shall be as the mechanisms used to develop various PPVPN solutions SHALL be as
common as possible with generic Internet infrastructure mechanisms common as possible with generic Internet infrastructure mechanisms
like discovery, signaling, routing and management. At the same time, like discovery, signaling, routing and management. At the same time,
existing Internet infrastructure mechanisms shall not be overloaded. existing Internet infrastructure mechanisms SHALL NOT be overloaded.
Another generic requirement from a standardization perspective is to Another generic requirement from a standardization perspective is to
limit the number of different solution approaches. For example, for limit the number of different solution approaches. For example, for
service providers that need to support multiple types of VPN service providers that need to support multiple types of VPN
services, it may be undesirable to require a completely different services, it may be undesirable to require a completely different
solution approach for each type of VPN service. solution approach for each type of VPN service.
1.2. Deployment Scenarios 1.2. Deployment Scenarios
There are three different deployment scenarios that need to be There are three different deployment scenarios that need to be
skipping to change at page 5, line 21 skipping to change at page 5, line 23
for the PPVPN customer. This scenario can be generalized to cover the for the PPVPN customer. This scenario can be generalized to cover the
Internet, which comprises of multiple service provider networks. It Internet, which comprises of multiple service provider networks. It
should be noted that customers can construct their own VPNs across should be noted that customers can construct their own VPNs across
multiple providers. However such VPNs are not considered here as multiple providers. However such VPNs are not considered here as
they would not be "Provider-provisioned". they would not be "Provider-provisioned".
A fourth scenario, "Carrier's carrier" VPN may also be considered. In A fourth scenario, "Carrier's carrier" VPN may also be considered. In
this scenario, a service provider (for example, a Tier 1 service this scenario, a service provider (for example, a Tier 1 service
provider) provides VPN service to another service provider (for provider) provides VPN service to another service provider (for
example, a Tier 2 service provider), which in turn provides VPN example, a Tier 2 service provider), which in turn provides VPN
service on its VPN to its customers. In the example given above, service on its VPN to its customers. In the example given above, the
the Tier 2 provider's customers are contained within the Tier 2 provider's Tier 2 provider's customers are contained within the Tier 2
network, and the Tier 2 provider itself is a customer of the Tier 1 provider's network, and the Tier 2 provider itself is a customer of
provider's network. Thus, this scenario is not treated separately the Tier 1 provider's network. Thus, this scenario is not treated
in the document, because all of the single provider requirements separately in the document, because all of the single provider
would apply equally to this case. requirements would apply equally to this case.
It is expected that many of the generic requirements described in It is expected that many of the generic requirements described in
this document are independent of the three deployment scenarios this document are independent of the three deployment scenarios
listed above. However, specific requirements that are indeed listed above. However, specific requirements that are indeed
dependent on the deployment scenario will be pointed out in this dependent on the deployment scenario will be pointed out in this
document. document.
1.3. Outline of this document 1.3. Outline of this document
This document describes generic requirements for Provider Provisioned This document describes generic requirements for Provider Provisioned
skipping to change at page 6, line 45 skipping to change at page 6, line 45
were part of the Service Provider focus group whose intentions were were part of the Service Provider focus group whose intentions were
to present Service Provider view on the general requirements for to present Service Provider view on the general requirements for
PPVPN. A significant set of requirements were directly taken from PPVPN. A significant set of requirements were directly taken from
previous work by the PPVPN WG to develop requirements for Layer 3 previous work by the PPVPN WG to develop requirements for Layer 3
PPVPN [L3REQTS]. The existing work in the L2 requirements area has PPVPN [L3REQTS]. The existing work in the L2 requirements area has
also influenced the contents of this document [L2REQTS]. also influenced the contents of this document [L2REQTS].
Besides the editor, the following are the authors that contributed to Besides the editor, the following are the authors that contributed to
this document: this document:
Loa Andersson Loa Andersson (loa@pi.se)
Ron Bonica Ron Bonica (ronald.p.bonica@mci.com)
Dave McDysan Dave McDysan (dave.mcdysan@mci.com)
Junichi Sumimoto Junichi Sumimoto (sumimoto.junichi@lab.ntt.co.jp)
Muneyoshi Suzuki Muneyoshi Suzuki (suzuki.muneyoshi@lab.ntt.co.jp)
David Meyer David Meyer (dmm@1-4-5.net)
Marco Carugi Marco Carugi (marco.carugi@nortelnetworks.com)
Yetik Serbest Yetik Serbest (yetik_serbest@labs.sbc.com)
Luyuan Fang Luyuan Fang (luyuanfang@att.com)
Javier Achirica Javier Achirica (achirica@telefonica.net)
3. Definitions and Taxonomy 3. Definitions and Taxonomy
The terminology used in this document is defined in [TERMINOLOGY]. In The terminology used in this document is defined in [TERMINOLOGY]. In
addition the following terminology is used: addition the following terminology is used:
Site: a geographical location with one or more users or one or more Site: a geographical location with one or more users or one or more
servers or a combination of servers and users. servers or a combination of servers and users.
User: the end user equipment (hosts), e.g., a workstation. User: the end user equipment (hosts), e.g., a workstation.
PPVPN PPVPN
________________|__________________ ________________|__________________
| | | |
Layer 2 (L2) Layer 3 (L3) Layer 2 (L2) Layer 3 (L3)
______|_____ ______|________ ______|_____ ______|________
| | | | | | | |
PE-based CE-based PE-based CE-based PE-based CE-based PE-based CE-based
| |__________|
|___________ ______|_____
| | | |
P2P P2MP P2P P2MP
The figure above presents a taxonomy of PPVPN technologies. Although The figure above presents a taxonomy of PPVPN technologies. PE-based
the above figure shows the classification for PE-based Layer 2 VPNs, and CE-based Layer 2 VPNs may also be further classified as point-to-
it should be noted that CE-based Layer 2 PPVPNs may also be further point (P2P) or point-to-multipoint (P2MP). It is also the intention
classified as point-to-point (P2P) or point-to-multipoint (P2MP). It of the working group to have a limited number of solutions, and this
is also the intention of the working group to have a limited number goal must be kept in mind when proposing solutions that meet the
of solutions, and this goal must be kept in mind when proposing requirements specified in this document. Definitions for CE-based and
solutions that meet the requirements specified in this document. PE-based PPVPNs can be obtained from [L3 FRAMEWORK]. Layer 2
Definitions for CE-based and PE-based PPVPNs can be obtained from specific definitions can be obtained from [L2FRAMEWORK].
[L3FRAMEWORK]. Layer 2 specific definitions can be obtained from
[L2FRAMEWORK].
4. Service requirements 4. Service requirements
These are the requirements that a customer can observe or measure, in These are the requirements that a customer can observe or measure, in
order to verify if the PPVPN service that the Service Provider (SP) order to verify if the PPVPN service that the Service Provider (SP)
provides is satisfactory. As mentioned before, each of these provides is satisfactory. As mentioned before, each of these
requirements apply equally across each of the three deployment requirements apply equally across each of the three deployment
scenarios unless stated otherwise. scenarios unless stated otherwise.
4.1. Availability 4.1. Availability
VPN services must have high availability. VPNs that are distributed VPN services MUST have high availability. VPNs that are distributed
over several sites require connectivity to be maintained even in the over several sites require connectivity to be maintained even in the
event of network failures or degraded service. event of network failures or degraded service.
This can be achieved via various redundancy techniques such as: This can be achieved via various redundancy techniques such as:
1. Physical Diversity 1. Physical Diversity
A single site connected to multiple CEs (for CE-based PPVPNs) or PEs A single site connected to multiple CEs (for CE-based PPVPNs) or PEs
(for PE-based PPVPNs), or different POPs, or even different service (for PE-based PPVPNs), or different POPs, or even different service
providers. providers
2. Tunnel redundancy 2. Tunnel redundancy
Redundant tunnels may be set up between the PEs (in a PE-based PPVPN) Redundant tunnels may be set up between the PEs (in a PE-based PPVPN)
or the CEs (in a CE-based PPVPN) so that if one tunnel fails, VPN or the CEs (in a CE-based PPVPN) so that if one tunnel fails, VPN
traffic can continue to flow across the other tunnel that has already traffic can continue to flow across the other tunnel that has already
been set-up in advance. been set-up in advance.
Tunnel redundancy may be provided over and above physical diversity. Tunnel redundancy may be provided over and above physical diversity.
For example, a single site may be connected to two CEs (for CE-based For example, a single site may be connected to two CEs (for CE-based
skipping to change at page 9, line 7 skipping to change at page 9, line 7
consequently, management of additional resources, which would impact consequently, management of additional resources, which would impact
the overall scaling of the service. the overall scaling of the service.
It should be noted that it is difficult to guarantee high It should be noted that it is difficult to guarantee high
availability when the VPN service is across multiple providers, availability when the VPN service is across multiple providers,
unless there is a negotiation between the different service providers unless there is a negotiation between the different service providers
to maintain the service level agreement for the VPN customer. to maintain the service level agreement for the VPN customer.
4.2. Stability 4.2. Stability
In addition to availability, VPN services must also be stable. In addition to availability, VPN services MUST also be stable.
Stability is a function of several components such as VPN routing, Stability is a function of several components such as VPN routing,
signaling and discovery mechanisms, in addition to tunnel stability. signaling and discovery mechanisms, in addition to tunnel stability.
For example, in the case of routing, route flapping or routing loops For example, in the case of routing, route flapping or routing loops
must be avoided in order to ensure stability. Stability of the VPN MUST be avoided in order to ensure stability. Stability of the VPN
service is directly related to the stability of the mechanisms and service is directly related to the stability of the mechanisms and
protocols used to establish the service. It should also be possible protocols used to establish the service. It SHOULD also be possible
to allow network upgrades and maintenance procedures without to allow network upgrades and maintenance procedures without
impacting the VPN service. impacting the VPN service.
4.3. Traffic types 4.3. Traffic types
VPN services must support unicast (or point to point) traffic and VPN services MUST support unicast (or point to point) traffic and
should support any-to-any or point-to-multipoint traffic including SHOULD support any-to-any or point-to-multipoint traffic including
multicast and broadcast traffic. In the broadcast model, the network multicast and broadcast traffic. In the broadcast model, the network
delivers a stream to all members of a subnetwork, regardless of their delivers a stream to all members of a subnetwork, regardless of their
interest in that stream. In the multicast model, the network delivers interest in that stream. In the multicast model, the network delivers
a stream to a set of destinations that have registered interest in a stream to a set of destinations that have registered interest in
the stream. All destinations need not belong to the same subnetwork. the stream. All destinations need not belong to the same subnetwork.
Multicast is more applicable to L3 VPNs while broadcast is more Multicast is more applicable to L3 VPNs while broadcast is more
applicable to L2VPNs. It is desirable to support multicast limited applicable to L2VPNs. It is desirable to support multicast limited
in scope to an intranet or extranet. The solution should be able to in scope to an intranet or extranet. The solution SHOULD be able to
support a large number of such intranet or extranet specific support a large number of such intranet or extranet specific
multicast groups in a scalable manner. multicast groups in a scalable manner.
All PPVPN approaches shall support both IPv4 and IPv6 traffic. All PPVPN approaches SHALL support both IPv4 and IPv6 traffic.
Specific L2 traffic types (e.g., ATM, Frame Relay and Ethernet) shall 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 be supported via encapsulation in IP or MPLS tunnels in the case of
L2VPNs. L2VPNs.
4.4. Data isolation 4.4. Data isolation
The PPVPN must support forwarding plane isolation. The network must The PPVPN MUST support forwarding plane isolation. The network MUST
never deliver user data across VPN boundaries unless the two VPNs never deliver user data across VPN boundaries unless the two VPNs
participate in an intranet or extranet. participate in an intranet or extranet.
Furthermore, if the provider network receives signaling or routing Furthermore, if the provider network receives signaling or routing
information from one VPN, it must not reveal that information to information from one VPN, it MUST NOT reveal that information to
another VPN unless the two VPNs participate in an intranet or another VPN unless the two VPNs participate in an intranet or
extranet. It should be noted that the disclosure of any extranet. It should be noted that the disclosure of any
signaling/routing information across an extranet must be filtered per signaling/routing information across an extranet MUST be filtered per
the extranet agreement between the organizations participating in the the extranet agreement between the organizations participating in the
extranet. extranet.
4.5. Security 4.5. Security
A range of security features should be supported by the suite of A range of security features SHOULD be supported by the suite of
PPVPN solutions in the form of securing customer flows, providing PPVPN solutions in the form of securing customer flows, providing
authentication services for temporary, remote or mobile users, and authentication services for temporary, remote or mobile users, and
the need to protect service provider resources involved in supporting the need to protect service provider resources involved in supporting
a PPVPN. These security features should be implemented based on the a PPVPN. These security features SHOULD be implemented based on the
framework outlined in [VPN SEC]. Each PPVPN solution should state framework outlined in [VPN SEC]. Each PPVPN solution SHOULD state
which security features it supports and how such features can be which security features it supports and how such features can be
configured on a per customer basis. Protection against Denial of configured on a per customer basis. Protection against Denial of
Service (DoS) attacks is a key component of security mechanisms. Service (DoS) attacks is a key component of security mechanisms.
Examples of DoS attacks include attacks to the PE or CE CPUs, access Examples of DoS attacks include attacks to the PE or CE CPUs, access
connection congestion, TCP SYN attacks and ping attacks. connection congestion, TCP SYN attacks and ping attacks.
Some security mechanisms (such as use of IPsec on a CE-to-CE basis) Some security mechanisms (such as use of IPsec on a CE-to-CE basis)
may be equally useful regardless of the scope of the VPN. Other may be equally useful regardless of the scope of the VPN. Other
mechanisms may be more applicable in some scopes than in others. For mechanisms may be more applicable in some scopes than in others. For
example, in some cases of single-provider single-AS VPNs, the VPN example, in some cases of single-provider single-AS VPNs, the VPN
service may be isolated from some forms of attack by isolating the service may be isolated from some forms of attack by isolating the
infrastructure used for supporting VPNs from the infrastructure used infrastructure used for supporting VPNs from the infrastructure used
for other services. However, the requirements for security are common for other services. However, the requirements for security are common
regardless of the scope of the VPN service. regardless of the scope of the VPN service.
4.5.1. User data security 4.5.1. User data security
PPVPN solutions that support user data security should use standard PPVPN solutions that support user data security SHOULD use standard
methods (e.g., IPsec) to achieve confidentiality, integrity, methods (e.g., IPsec) to achieve confidentiality, integrity,
authentication and replay attack prevention. Such security methods authentication and replay attack prevention. Such security methods
must be configurable between different end points, such as CE-CE, PE- 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- PE, and CE-PE. It is also desirable to configure security on a per-
route or per-VPN basis. User data security using encryption is route or per-VPN basis. User data security using encryption is
especially desirable in the multi-provider scenario. especially desirable in the multi-provider scenario.
4.5.2. Access control 4.5.2. Access control
A PPVPN solution may also have the ability to activate the A PPVPN solution may also have the ability to activate the
appropriate filtering capabilities upon request of a customer. A appropriate filtering capabilities upon request of a customer. A
filter provides a mechanism so that access control can be invoked at filter provides a mechanism so that access control can be invoked at
the point(s) of communication between different organizations the point(s) of communication between different organizations
involved in an extranet. Access control can be implemented by a involved in an extranet. Access control can be implemented by a
firewall, access control lists on routers, cryptographic mechanisms firewall, access control lists on routers, cryptographic mechanisms
or similar mechanisms to apply policy-based access control. Access or similar mechanisms to apply policy-based access control. Access
control must also be applicable between CE-CE, PE-PE and CE-PE. Such control MUST also be applicable between CE-CE, PE-PE and CE-PE. Such
access control mechanisms are desirable in the multi-provider access control mechanisms are desirable in the multi-provider
scenario. scenario.
4.5.3. Site authentication and authorization 4.5.3. Site authentication and authorization
A PPVPN solution requires authentication and authorization of the A PPVPN solution requires authentication and authorization of the
following: following:
- temporary and permanent access for users connecting to sites - temporary and permanent access for users connecting to sites
(authentication and authorization BY the site) (authentication and authorization BY the site)
- the site itself (authentication and authorization FOR the site) - the site itself (authentication and authorization FOR the site)
4.5.4. Inter domain security 4.5.4. Inter domain security
The VPN solution must have appropriate security mechanisms to prevent The VPN solution MUST have appropriate security mechanisms to prevent
the different kinds of Distributed Denial of Service (DDoS) attacks the different kinds of Distributed Denial of Service (DDoS) attacks
mentioned earlier, misconfiguration or unauthorized accesses in inter mentioned earlier, misconfiguration or unauthorized accesses in inter
domain PPVPN connections. This is particularly important for multi- domain PPVPN connections. This is particularly important for multi-
service provider deployment scenarios. However, this will also be service provider deployment scenarios. However, this will also be
important in single-provider multi-AS scenarios. important in single-provider multi-AS scenarios.
4.6. Topology 4.6. Topology
A VPN should support arbitrary, customer-defined inter-site A VPN SHOULD support arbitrary, customer-defined inter-site
connectivity, ranging, for example, from hub-and-spoke, partial mesh connectivity, ranging, for example, from hub-and-spoke, partial mesh
to full mesh topology. These can actually be different from the to full mesh topology. These can actually be different from the
topology used by the service provider. To the extent possible, a topology used by the service provider. To the extent possible, a
PPVPN service should be independent of the geographic extent of the PPVPN service SHOULD be independent of the geographic extent of the
deployment. deployment.
Multiple VPNs per customer site should be supported without requiring Multiple VPNs per customer site SHOULD be supported without requiring
additional hardware resources per VPN. This should also include a additional hardware resources per VPN. This SHOULD also include a
free mix of L2 and L3 VPNs. free mix of L2 and L3 VPNs.
To the extent possible, the PPVPN services should be independent of To the extent possible, the PPVPN services SHOULD be independent of
access network technology. access network technology.
4.7. Addressing 4.7. Addressing
Each customer resource must be identified by an address that is Each customer resource MUST be identified by an address that is
unique within its VPN. It need not be identified by a globally unique unique within its VPN. It need not be identified by a globally unique
address. address.
Support for private addresses as described in RFC 1918, as well as Support for private addresses as described in RFC 1918, as well as
overlapping customer addresses shall be supported. One or more VPNs overlapping customer addresses SHALL be supported. One or more VPNs
for each customer can be built over the same infrastructure without for each customer can be built over the same infrastructure without
requiring any of them to renumber. The solution MUST NOT use NAT on requiring any of them to renumber. The solution MUST NOT use NAT on
the customer traffic to achieve that goal. Interconnection of two the customer traffic to achieve that goal. Interconnection of two
networks with overlapping IP addresses is outside the scope of this networks with overlapping IP addresses is outside the scope of this
document. document.
A VPN service shall be capable of supporting non-IP customer A VPN service SHALL be capable of supporting non-IP customer
addresses via encapsulation techniques, if it is a Layer 2 VPN (e.g., addresses via encapsulation techniques, if it is a Layer 2 VPN (e.g.,
Frame Relay, ATM, Ethernet). Support for non-IP Layer 3 addresses Frame Relay, ATM, Ethernet). Support for non-IP Layer 3 addresses
may be desirable in some cases, but is beyond the scope of VPN may be desirable in some cases, but is beyond the scope of VPN
solutions developed in the IETF, and therefore, this document. solutions developed in the IETF, and therefore, this document.
4.8. Quality of Service 4.8. Quality of Service
A technical approach for supporting VPNs shall be able to support QoS A technical approach for supporting VPNs SHALL be able to support QoS
via IETF standardized mechanisms such as Diffserv. Support for best- via IETF standardized mechanisms such as Diffserv. Support for best-
effort traffic shall be mandatory for all PPVPN types. The extent to effort traffic SHALL be mandatory for all PPVPN types. The extent to
which any specific VPN service will support QoS is up to the service which any specific VPN service will support QoS is up to the service
provider. In many cases single-provider single-AS VPNs will offer QoS provider. In many cases single-provider single-AS VPNs will offer QoS
guarantees. Support of QoS guarantees in the multi-service-provider guarantees. Support of QoS guarantees in the multi-service-provider
case will require cooperation between the various service providers case will require cooperation between the various service providers
involved in offering the service. involved in offering the service.
It should be noted that QoS mechanisms in the multi-provider scenario It should be noted that QoS mechanisms in the multi-provider scenario
requires each of the participating providers to support the REQUIRES each of the participating providers to support the
mechanisms being used, and as such, this is difficult to achieve. mechanisms being used, and as such, this is difficult to achieve.
Note that all cases involving QoS may require that the CE and/or PE Note that all cases involving QoS may require that the CE and/or PE
perform shaping and/or policing. perform shaping and/or policing.
The need to provide QoS will occur primarily in the access network, 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 that will often be the bottleneck. This is likely to occur
since the backbone effectively statistically multiplexes many users, since the backbone effectively statistically multiplexes many users,
and is traffic engineered or includes capacity for restoration and and is traffic engineered or includes capacity for restoration and
growth. Hence in most cases PE-PE QoS is not a major issue. As far as growth. Hence in most cases PE-PE QoS is not a major issue. As far as
access QoS is concerned, there are two directions of QoS management access QoS is concerned, there are two directions of QoS management
that should be considered in any PPVPN service regarding QoS: that may be considered in any PPVPN service regarding QoS:
- From the CE across the access network to the PE - From the CE across the access network to the PE
- From the PE across the access network to CE - From the PE across the access network to CE
PPVPN CE and PE devices should be capable of supporting QoS across at PPVPN CE and PE devices SHOULD be capable of supporting QoS across at
least the following subset of access networks, as applicable to the least the following subset of access networks, as applicable to the
specific type of PPVPN (L2 or L3). However, to the extent possible, specific type of PPVPN (L2 or L3). However, to the extent possible,
the QoS capability of a PPVPN should be independent of the access the QoS capability of a PPVPN SHOULD be independent of the access
network technology: network technology:
- ATM Virtual Connections (VCs) - ATM Virtual Connections (VCs)
- Frame Relay Data Link Connection Identifiers (DLCIs) - Frame Relay Data Link Connection Identifiers (DLCIs)
- 802.1d Prioritized Ethernet - 802.1d Prioritized Ethernet
- MPLS-based access - MPLS-based access
- Multilink Multiclass PPP - Multilink Multiclass PPP
- QoS-enabled wireless (e.g., LMDS, MMDS) - QoS-enabled wireless (e.g., LMDS, MMDS)
- Cable modem - Cable modem
- QoS-enabled Digital Subscriber Line (DSL) - QoS-enabled Digital Subscriber Line (DSL)
skipping to change at page 14, line 23 skipping to change at page 14, line 23
- Delay and delay variation (jitter) bounds - Delay and delay variation (jitter) bounds
- Packet ordering, at least when transporting L2 services - Packet ordering, at least when transporting L2 services
sensitive to reordering (e.g., ATM). sensitive to reordering (e.g., ATM).
The above list contains items from [Y.1241], as well as other items The above list contains items from [Y.1241], as well as other items
typically part of SLAs for currently deployed VPN services [FRF.13]. typically part of SLAs for currently deployed VPN services [FRF.13].
See [RFC3198] for generic definitions of SLS, SLA, and SLO. See [RFC3198] for generic definitions of SLS, SLA, and SLO.
The provider network management system shall measure, and report as The provider network management system SHALL measure, and report as
necessary, whether measured performance meets or fails to meet the necessary, whether measured performance meets or fails to meet the
above SLS objectives. above SLS objectives.
In many cases the guaranteed levels for Service Level Objective (SLO) In many cases the guaranteed levels for Service Level Objective (SLO)
parameters may depend upon the scope of the VPN. For example, one parameters may depend upon the scope of the VPN. For example, one
level of guarantee might be provided for service within a single AS. level of guarantee might be provided for service within a single AS.
A different (generally less stringent) guarantee might be provided A different (generally less stringent) guarantee might be provided
within multiple ASs within a single service provider. At the current within multiple ASs within a single service provider. At the current
time, in most cases specific guarantees are not offered for multi- time, in most cases specific guarantees are not offered for multi-
provider VPNs, and if guarantees were offered they might be expected provider VPNs, and if guarantees were offered they might be expected
skipping to change at page 14, line 45 skipping to change at page 14, line 45
The service provider and the customer may negotiate a contractual The service provider and the customer may negotiate a contractual
arrangement that includes a Service Level Agreement (SLA) regarding arrangement that includes a Service Level Agreement (SLA) regarding
compensation if the provider does not meet an SLS performance compensation if the provider does not meet an SLS performance
objective. Details of such compensation are outside the scope of this objective. Details of such compensation are outside the scope of this
document. document.
4.10. Network Resource Partitioning and Sharing between VPNs 4.10. Network Resource Partitioning and Sharing between VPNs
Network resources such as memory space, FIB table, bandwidth and CPU Network resources such as memory space, FIB table, bandwidth and CPU
processing shall be shared between VPNs and, where applicable, with processing SHALL be shared between VPNs and, where applicable, with
non-VPN Internet traffic. Mechanisms should be provided to prevent non-VPN Internet traffic. Mechanisms SHOULD be provided to prevent
any specific VPN from taking up available network resources and any specific VPN from taking up available network resources and
causing others to fail. SLAs to this effect should be provided to the causing others to fail. SLAs to this effect SHOULD be provided to the
customer. customer.
Similarly, resources used for control plane mechanisms are also Similarly, resources used for control plane mechanisms are also
shared. When the service provider's control plane is used to shared. When the service provider's control plane is used to
distribute VPN specific information and provide other control distribute VPN specific information and provide other control
mechanisms for VPNs, there shall be mechanisms to ensure that control mechanisms for VPNs, there SHALL be mechanisms to ensure that control
plane performance is not degraded below acceptable limits when plane performance is not degraded below acceptable limits when
scaling the VPN service, or during network events such as failure, scaling the VPN service, or during network events such as failure,
routing instabilities etc. Since a service provider's network would routing instabilities etc. Since a service provider's network would
also be used to provide Internet service, in addition to VPNs, also be used to provide Internet service, in addition to VPNs,
mechanisms to ensure the stable operation of Internet services and mechanisms to ensure the stable operation of Internet services and
other VPNs shall be made in order to avoid adverse effects of other VPNs SHALL be made in order to avoid adverse effects of
resource hogging by large VPN customers. resource hogging by large VPN customers.
5. Provider requirements 5. Provider requirements
This section describes operational requirements for a cost-effective, This section describes operational requirements for a cost-effective,
profitable VPN service offering. profitable VPN service offering.
5.1. Scalability 5.1. Scalability
The scalability for VPN solutions has many aspects. The list below is The scalability for VPN solutions has many aspects. The list below is
intended to comprise of the aspects that PPVPN solutions should intended to comprise of the aspects that PPVPN solutions SHOULD
address. Clearly these aspects in absolute figures are very different address. Clearly these aspects in absolute figures are very different
for different types of VPNs - i.e., a point to point service has only 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. 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 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 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 three users should be as viable as a VPN with hundreds of
sites and thousands of users. sites and thousands of users.
5.1.1. Service Provider Capacity Sizing Projections 5.1.1. Service Provider Capacity Sizing Projections
A PPVPN solution should be scalable to support a very large number of A PPVPN solution SHOULD be scalable to support a very large number of
VPNs per Service Provider network. The estimate is that a large VPNs per Service Provider network. The estimate is that a large
service provider will require support for O(10^4) VPNs within four service provider will require support for O(10^4) VPNs within four
years. years.
A PPVPN solution should be scalable to support a wide range of number 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 of site interfaces per VPN, depending on the size and/or structure of
the customer organization. The number of site interfaces should range the customer organization. The number of site interfaces SHOULD range
from a few site interfaces to over 50,000 site interfaces per VPN. 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 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 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)), just a few to the number of routes exchanged between ISPs (O(10^5)),
with typical values being in the O(10^3) range. The high end number with typical values being in the O(10^3) range. The high end number
is especially true considering the fact that many large ISPs may is especially true considering the fact that many large ISPs may
provide VPN services to smaller ISPs or large corporations. provide VPN services to smaller ISPs or large corporations.
Typically, the number of routes per VPN is at least twice the number Typically, the number of routes per VPN is at least twice the number
of site interfaces. of site interfaces.
A PPVPN solution should support high values of the frequency of A PPVPN solution SHOULD support high values of the frequency of
configuration setup and change, e.g., for real-time provisioning of configuration setup and change, e.g., for real-time provisioning of
an on-demand videoconferencing VPN or addition/deletion of sites. an on-demand videoconferencing VPN or addition/deletion of sites.
Approaches should articulate scaling and performance limits for more Approaches SHOULD articulate scaling and performance limits for more
complex deployment scenarios, such as single-provider multi-AS VPNs, complex deployment scenarios, such as single-provider multi-AS VPNs,
multi-provider VPNs and carriers' carrier. Approaches should also multi-provider VPNs and carriers' carrier. Approaches SHOULD also
describe other dimensions of interest, such as capacity requirements describe other dimensions of interest, such as capacity requirements
or limits, number of interworking instances supported as well as any or limits, number of interworking instances supported as well as any
scalability implications on management systems. scalability implications on management systems.
A PPVPN solution should support a large number of customer interfaces 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 on a single PE (for PE-based PPVPN) or CE (for CE-based PPVPN) with
current Internet protocols. current Internet protocols.
5.1.2. VPN Scalability aspects 5.1.2. VPN Scalability aspects
This section describes the metrics for scaling PPVPN solutions, This section describes the metrics for scaling PPVPN solutions,
points out some of the scaling differences between L2 and L3 VPNs. It points out some of the scaling differences between L2 and L3 VPNs. It
should be noted that the scaling numbers used in this document must should be noted that the scaling numbers used in this document must
be treated as typical examples as seen by the authors of this be treated as typical examples as seen by the authors of this
document. These numbers are only representative and different service document. These numbers are only representative and different service
providers may have different requirements for scaling. Further providers may have different requirements for scaling. Further
discussion on service provider sizing projections is in Section discussion on service provider sizing projections is in Section
5.1.1. Please note that the terms "user" and "site" are as defined 5.1.1. Please note that the terms "user" and "site" are as defined
in Section 3. It should also be noted that the numbers given below in Section 3. It should also be noted that the numbers given below
would be different depending on whether the scope of the VPN is would be different depending on whether the scope of the VPN is
single-provider single-AS, single-provider multi-AS, or multi- single-provider single-AS, single-provider multi-AS, or multi-
provider. Clearly, the larger the scope, the larger the numbers that provider. Clearly, the larger the scope, the larger the numbers that
may need to be supported. However, this also means more management may need to be supported. However, this also means more management
issues. The numbers below may be treated as representative of the issues. The numbers below may be treated as representative of the
single-provider case. single-provider case.
5.1.2.1. Number of users per site 5.1.2.1. Number of users per site
The number of users per site follows the same logic as for users per 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 VPN. Further, it must be possible to have single user sites connected
to the same VPN as very large sites are connected to. to the same VPN as very large sites are connected to.
L3 VPNs must scale from 1 user per site to O(10^4) per site. L2 VPNs L3 VPNs SHOULD scale from 1 user per site to O(10^4) per site. L2
must scale from 1 user to O(10^3) per site for point-to-point VPNs VPNs SHOULD scale from 1 user to O(10^3) per site for point-to-point
and to O(10^4) for point-to-multipoint VPNs. VPNs and to O(10^4) for point-to-multipoint VPNs.
5.1.2.2. Number of sites per VPN 5.1.2.2. Number of sites per VPN
The number of sites per VPN clearly depends on the number of users 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 per site. VPNs SHOULD scale from 2 to O(10^3) sites per VPN. These
numbers are usually limited by device memory. numbers are usually limited by device memory.
5.1.2.3. Number of PEs and CEs 5.1.2.3. Number of PEs and CEs
The number of PEs that supports the same set of VPNs, i.e., the 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- number of PEs that needs to directly exchange information on VPN de-
multiplexing information is clearly a scaling factor in a PE-based 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 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 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- 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 SP or multi-AS network. Typically, this number SHOULD be as low as
possible in order to make the VPN cost effective and manageable. possible in order to make the VPN cost effective and manageable.
5.1.2.4. Number of sites per PE 5.1.2.4. Number of sites per PE
The number of sites per PE needs to be discussed based on several 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 different scenarios. On the one hand there is a limitation to the
number of customer facing interfaces that the PE can support. On the number of customer facing interfaces that the PE can support. On the
other hand the access network may aggregate several sites connected other hand the access network may aggregate several sites connected
on comparatively low bandwidth on to one single high bandwidth on comparatively low bandwidth on to one single high bandwidth
interface on the PE. The scaling point here is that the PE must be interface on the PE. The scaling point here is that the PE SHOULD be
able to support a few or even a single site on the low end and 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 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 memory. Implementations of PPVPN solutions may be evaluated based on
this requirement, because it directly impacts cost and manageability this requirement, because it directly impacts cost and manageability
of a VPN. of a VPN.
5.1.2.5. Number of VPNs in the network 5.1.2.5. Number of VPNs in the network
The number of VPNs should scale linearly with the size of the access 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, 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 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 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 SHOULD 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 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 VPN, the number of tunnels in the core network may be fewer, because
of the possibility of tunnel aggregation or multiplexing across the of the possibility of tunnel aggregation or multiplexing across the
core. core.
5.1.2.6. Number of VPNs per customer 5.1.2.6. Number of VPNs per customer
In some cases a service provider may support multiple VPNs for the In some cases a service provider may support multiple VPNs for the
same customer of that service provider. For example, this may occur same customer of that service provider. For example, this may occur
due to differences in services offered per VPN (e.g., different QoS, due to differences in services offered per VPN (e.g., different QoS,
security levels, or reachability) as well as due to the presence of security levels, or reachability) as well as due to the presence of
multiple workgroups per customer. It is possible that one customer multiple workgroups per customer. It is possible that one customer
will run up to O(100) VPNs. will run up to O(100) VPNs.
5.1.2.7. Number of addresses and address prefixes per VPN 5.1.2.7. Number of addresses and address prefixes per VPN
Since any VPN solution shall support private customer addresses, the Since any VPN solution SHALL support private customer addresses, the
number of addresses and address prefixes are important in evaluating number of addresses and address prefixes are important in evaluating
the scaling requirements. The number of address prefixes used in the scaling requirements. The number of address prefixes used in
routing protocols and in forwarding tables specific to the VPN needs routing protocols and in forwarding tables specific to the VPN needs
to scale from very few (for smaller customers) to very large numbers to scale from very few (for smaller customers) to very large numbers
seen in typical Service Provider backbones. The high end is seen in typical Service Provider backbones. The high end is
especially true considering that many Tier 1 SPs may provide VPN 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 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 number would be on the order of addresses supported in typical native
Layer 2 backbones. Layer 2 backbones.
5.1.3. Solution-Specific Metrics 5.1.3. Solution-Specific Metrics
Each PPVPN solution shall document its scalability characteristics in Each PPVPN solution SHALL document its scalability characteristics in
quantitative terms. A VPN solution should quantify the amount of quantitative terms. A VPN solution SHOULD quantify the amount of
state that a PE and P device must support. This should be stated in state that a PE and P device has to support. This SHOULD be stated in
terms of the order of magnitude of the number of VPNs and site terms of the order of magnitude of the number of VPNs and site
interfaces supported by the service provider. Ideally, all VPN- interfaces supported by the service provider. Ideally, all VPN-
specific state should be contained in the PE device for a PE-based 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 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 device for a CE-based VPN. In all cases, the backbone routers (P
devices) shall not maintain VPN-specific state as far as possible. devices) SHALL NOT maintain VPN-specific state as far as possible.
Another metric is that of complexity. In a PE-based solution the PE Another metric is that of complexity. In a PE-based solution the PE
is more complex in that it must maintain tunnel-specific information is more complex in that it has to maintain tunnel-specific
for each VPN, but the CE is simpler since it does not need to support information for each VPN, but the CE is simpler since it does not
tunnels. On the other hand, in a CE-based solution, the CE is more need to support tunnels. On the other hand, in a CE-based solution,
complex since it must implement routing across a number of tunnels to the CE is more complex since it has to implement routing across a
other CEs in the VPN, but the PE is simpler since it has only one number of tunnels to other CEs in the VPN, but the PE is simpler
routing and forwarding instance. Thus, the complexity of the PE or CE since it has only one routing and forwarding instance. Thus, the
must be noted in terms of their processing and management functions. complexity of the PE or CE SHOULD be noted in terms of their
processing and management functions.
5.2. Management 5.2. Management
A service provider must have a means to view the topology, A service provider MUST have a means to view the topology,
operational state, service order status, and other parameters operational state, service order status, and other parameters
associated with each customer's VPN. Furthermore, the service associated with each customer's VPN. Furthermore, the service
provider must have a means to view the underlying logical and provider MUST have a means to view the underlying logical and
physical topology, operational state, provisioning status, and other physical topology, operational state, provisioning status, and other
parameters associated with the equipment providing the VPN service(s) parameters associated with the equipment providing the VPN service(s)
to its customers. to its customers.
In the multi-provider scenario, it is unlikely that participating In the multi-provider scenario, it is unlikely that participating
providers would provide each other a view to the network topology and providers would provide each other a view to the network topology and
other parameters mentioned above. However, each provider must ensure other parameters mentioned above. However, each provider MUST ensure
via management of their own networks that the overall VPN service via management of their own networks that the overall VPN service
offered to the customers are properly managed. In general the support offered to the customers are properly managed. In general the support
of a single VPN spanning multiple service providers requires close of a single VPN spanning multiple service providers requires close
cooperation between the service providers. One aspect of this cooperation between the service providers. One aspect of this
cooperation involves agreement on what information about the VPN will cooperation involves agreement on what information about the VPN will
be visible across providers, and what network management protocols be visible across providers, and what network management protocols
will be used between providers. will be used between providers.
VPN devices should provide standards-based management interfaces VPN devices SHOULD provide standards-based management interfaces
wherever feasible. wherever feasible.
5.2.1. Customer Management of a VPN 5.2.1. Customer Management of a VPN
A customer must have a means to view the topology, operational state, A customer SHOULD have a means to view the topology, operational
service order status, and other parameters associated with his or her state, service order status, and other parameters associated with his
VPN. or her VPN.
All aspects of management information about CE devices and customer All aspects of management information about CE devices and customer
attributes of a PPVPN manageable by an SP should be capable of being attributes of a PPVPN manageable by an SP SHOULD be capable of being
configured and maintained by the customer after being authenticated configured and maintained by the customer after being authenticated
and authorized. and authorized.
A customer should be able to make dynamic requests for changes to A customer SHOULD be able to make dynamic requests for changes to
traffic parameters. A customer should be able to receive real-time traffic parameters. A customer SHOULD be able to receive real-time
response from the SP network in response to these requests. One response from the SP network in response to these requests. One
example of such as service is a "Dynamic Bandwidth management" example of such as service is a "Dynamic Bandwidth management"
capability, that enables real-time response to customer requests for capability, that enables real-time response to customer requests for
changes of allocated bandwidth allocated to their VPN(s). A possible changes of allocated bandwidth allocated to their VPN(s). A possible
outcome of giving customers such capabilities is Denial of Service outcome of giving customers such capabilities is Denial of Service
attacks on other VPN customers or Internet users. This possibility is attacks on other VPN customers or Internet users. This possibility is
documented in the Security Considerations section. documented in the Security Considerations section.
6. Engineering requirements 6. Engineering requirements
These requirements are driven by implementation characteristics that These requirements are driven by implementation characteristics that
make service and provider requirements achievable. make service and provider requirements achievable.
6.1. Forwarding plane requirements 6.1. Forwarding plane requirements
VPN solutions should not pre-suppose or preclude the use of IETF VPN solutions SHOULD NOT pre-suppose or preclude the use of IETF
developed tunneling techniques such as IP-in-IP, L2TP, GRE, MPLS or developed tunneling techniques such as IP-in-IP, L2TP, GRE, MPLS or
IPsec. The separation of VPN solution and tunnels will facilitate IPsec. The separation of VPN solution and tunnels will facilitate
adaptability with extensions to current tunneling techniques or adaptability with extensions to current tunneling techniques or
development of new tunneling techniques. It should be noted that the development of new tunneling techniques. It should be noted that the
choice of the tunneling techniques may impact the service and scaling choice of the tunneling techniques may impact the service and scaling
capabilities of the VPN solution. capabilities of the VPN solution.
It should also be noted that specific tunneling techniques may not be It should also be noted that specific tunneling techniques may not be
feasible depending on the deployment scenario. In particular, there feasible depending on the deployment scenario. In particular, there
is currently very little use of MPLS in the inter-provider scenario. is currently very little use of MPLS in the inter-provider scenario.
Thus, native MPLS support may be needed between the service Thus, native MPLS support may be needed between the service
providers, or it would be necessary to run MPLS over IP or GRE. It providers, or it would be necessary to run MPLS over IP or GRE. It
should be noted that if MPLS is run over IP or GRE, some of the other should be noted that if MPLS is run over IP or GRE, some of the other
capabilities of MPLS, such as Traffic Engineering, would be impacted. capabilities of MPLS, such as Traffic Engineering, would be impacted.
Also note that a service provider may optionally choose to use a Also note that a service provider MAY optionally choose to use a
different encapsulation for multi-AS VPNs than is used for single AS different encapsulation for multi-AS VPNs than is used for single AS
VPNs. Similarly, a group of service providers may choose to use a VPNs. Similarly, a group of service providers may choose to use a
different encapsulation for multi-service provider VPNs than for VPNs different encapsulation for multi-service provider VPNs than for VPNs
within a single service provider. within a single service provider.
For Layer 2 VPNs, solutions should utilize the encapsulation For Layer 2 VPNs, solutions SHOULD utilize the encapsulation
techniques defined by PWE3, and should not impose any new techniques defined by the Pseudo-Wire Emulation Edge-to-Edge (PWE3)
requirements on these techniques. Working Group, and SHOULD NOT impose any new requirements on these
techniques.
PPVPN solutions must not impose any restrictions on the backbone PPVPN solutions MUST NOT impose any restrictions on the backbone
traffic engineering and management techniques. Conversely, backbone traffic engineering and management techniques. Conversely, backbone
engineering and management techniques must not affect the basic engineering and management techniques MUST NOT affect the basic
operation of a PPVPN, apart from influencing the SLA/SLS guarantees operation of a PPVPN, apart from influencing the SLA/SLS guarantees
associated with the service. The SP should, however, be required to associated with the service. The SP SHOULD, however, be REQUIRED to
provide per-VPN management, tunnel maintenance and other maintenance provide per-VPN management, tunnel maintenance and other maintenance
required in order to meet the SLA/SLS. required in order to meet the SLA/SLS.
By definition, VPN traffic should be segregated from each other, and 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 from non-VPN traffic in the network. After all, VPNs are a means of
dividing a physical network into several logical (virtual) networks. dividing a physical network into several logical (virtual) networks.
VPN traffic separation should be done in a scalable fashion. However, VPN traffic separation SHOULD be done in a scalable fashion. However,
safeguards should be made available against misbehaving VPNs to not safeguards SHOULD be made available against misbehaving VPNs to not
affect the network and other VPNs. affect the network and other VPNs.
A VPN solution should not impose any hard limit on the number of VPNs A VPN solution SHOULD NOT impose any hard limit on the number of VPNs
provided in the network. provided in the network.
6.2. Control plane requirements 6.2. Control plane requirements
The plug and play feature of a VPN solution with minimum The plug and play feature of a VPN solution with minimum
configuration requirements is an important consideration. The VPN configuration requirements is an important consideration. The VPN
solutions should have mechanisms for protection against customer solutions SHOULD have mechanisms for protection against customer
interface and/or routing instabilities so that they do not impact interface and/or routing instabilities so that they do not impact
other customers' services or impact general Internet traffic handling other customers' services or impact general Internet traffic handling
in any way. in any way.
A VPN should be provisioned with minimum number of steps. For 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 instance, a VPN need not be configured in every PE. For this to be
accomplished, an auto-configuration and an auto-discovery protocol, accomplished, an auto-configuration and an auto-discovery protocol,
which should be as common as possible to all VPN solutions, should be which SHOULD be as common as possible to all VPN solutions, SHOULD be
defined. However, these mechanisms should not adversely affect the defined. However, these mechanisms SHOULD NOT adversely affect the
cost, scalability or stability of a service by being overly complex, cost, scalability or stability of a service by being overly complex,
or by increasing layers in the protocol stack. or by increasing layers in the protocol stack.
Mechanisms to protect the SP network from effects of misconfiguration Mechanisms to protect the SP network from effects of misconfiguration
of VPNs should be provided. This is especially of importance in the of VPNs SHOULD be provided. This is especially of importance in the
multi-provider case, where misconfiguration could possibly impact multi-provider case, where misconfiguration could possibly impact
more than one network. more than one network.
6.3. Control Plane Containment 6.3. Control Plane Containment
The PPVPN control plane must include a mechanism through which the The PPVPN control plane MUST include a mechanism through which the
service provider can filter PPVPN related control plane information service provider can filter PPVPN related control plane information
as it passes between Autonomous Systems. For example, if a service as it passes between Autonomous Systems. For example, if a service
provider supports a PPVPN offering, but the service provider's provider supports a PPVPN offering, but the service provider's
neighbors do not participate in that offering, the service provider neighbors do not participate in that offering, the service provider
should not leak PPVPN control information into neighboring networks. SHOULD NOT leak PPVPN control information into neighboring networks.
Neighboring networks must be equipped with mechanisms that filter Neighboring networks MUST be equipped with mechanisms that filter
this information should the service provider leak it. This is this information should the service provider leak it. This is
important in the case of multi-provider VPNs as well as single- important in the case of multi-provider VPNs as well as single-
provider multi-AS VPNs. provider multi-AS VPNs.
6.4. Requirements related to commonality of PPVPN mechanisms with each 6.4. Requirements related to commonality of PPVPN mechanisms with each
other and with generic Internet mechanisms other and with generic Internet mechanisms
As far as possible, the mechanisms used to establish a VPN service As far as possible, the mechanisms used to establish a VPN service
should re-use well-known IETF protocols, limiting the need to define SHOULD re-use well-known IETF protocols, limiting the need to define
new protocols from scratch. It should, however, be noted that the use new protocols from scratch. It should, however, be noted that the use
of Internet mechanisms for the establishment and running of an of Internet mechanisms for the establishment and running of an
Internet-based VPN service, shall not affect the stability, Internet-based VPN service, SHALL NOT affect the stability,
robustness, and scalability of the Internet or Internet services. In robustness, and scalability of the Internet or Internet services. In
other words, these mechanisms should not conflict with the other words, these mechanisms SHOULD NOT conflict with the
architectural principles of the Internet, nor should it put at risk architectural principles of the Internet, nor SHOULD it put at risk
the existing Internet systems. For example, IETF-developed routing the existing Internet systems. For example, IETF-developed routing
protocols should be used for routing of L3 PPVPN traffic, without protocols SHOULD be used for routing of L3 PPVPN traffic, without
adding VPN-specific state to the Internet core routers. Similarly, adding VPN-specific state to the Internet core routers. Similarly,
well-known L2 technologies should be used in VPNs offering L2 well-known L2 technologies SHOULD be used in VPNs offering L2
services, without imposing risks to the Internet routers. A solution services, without imposing risks to the Internet routers. A solution
must be implementable without requiring additional functionality to MUST be implementable without requiring additional functionality to
the P devices in a network, and minimal functionality to the PE in a the P devices in a network, and minimal functionality to the PE in a
PE-based VPN and CE in a CE-based VPN. PE-based VPN and CE in a CE-based VPN.
In addition to commonality with generic Internet mechanisms, In addition to commonality with generic Internet mechanisms,
infrastructure mechanisms used in different PPVPN solutions (both L2 infrastructure mechanisms used in different PPVPN solutions (both L2
and L3), e.g., discovery, signaling, routing and management, should and L3), e.g., discovery, signaling, routing and management, SHOULD
be as common as possible. be as common as possible.
6.5. Interoperability 6.5. Interoperability
Each technical solution is expected to be based on interoperable Each technical solution is expected to be based on interoperable
Internet standards. Internet standards.
Multi-vendor interoperability at network element, network and service Multi-vendor interoperability at network element, network and service
levels among different implementations of the same technical solution levels among different implementations of the same technical solution
should be ensured (that will likely rely on the completeness of the SHOULD be ensured (that will likely rely on the completeness of the
corresponding standard). This is a central requirement for SPs and corresponding standard). This is a central requirement for SPs and
customers. customers.
The technical solution must be multi-vendor interoperable not only The technical solution MUST be multi-vendor interoperable not only
within the SP network infrastructure, but also with the customer's within the SP network infrastructure, but also with the customer's
network equipment and services making usage of the PPVPN service. network equipment and services making usage of the PPVPN service.
Customer access connections to a PPVPN solution may be different at Customer access connections to a PPVPN solution may be different at
different sites (e.g., Frame Relay on one site and Ethernet on different sites (e.g., Frame Relay on one site and Ethernet on
another). another).
Interconnection of a L2VPN over an L3VPN as if it were a customer Interconnection of a L2VPN over an L3VPN as if it were a customer
site shall be supported. However, interworking of Layer 2 site SHALL be supported. However, interworking of Layer 2
technologies is not required, and is outside the scope of the working technologies is not required, and is outside the scope of the working
group, and therefore, of this document. group, and therefore, of this document.
Inter-domain interoperability - It should be possible to deploy a Inter-domain interoperability - It SHOULD be possible to deploy a
PPVPN solution across domains, Autonomous Systems, or the Internet. PPVPN solution across domains, Autonomous Systems, or the Internet.
7. Security Considerations 7. Security Considerations
Security requirements for Provider Provisioned VPNs have been Security requirements for Provider Provisioned VPNs have been
described in Section 4.5. In addition, the following considerations described in Section 4.5. In addition, the following considerations
need to be kept in mind when a provider provisioned VPN service is need to be kept in mind when a provider provisioned VPN service is
provided across a public network infrastructure that is also used to provided across a public network infrastructure that is also used to
provide Internet connectivity. In general, the security framework provide Internet connectivity. In general, the security framework
described in [VPN-SEC] should be used as far as it is applicable to described in [VPN-SEC] SHOULD be used as far as it is applicable to
the given type of PPVPN service. the given type of PPVPN service.
The PE device has a lot of functionality required for the successful The PE device has a lot of functionality required for the successful
operation of the VPN service. The PE device is frequently also part operation of the VPN service. The PE device is frequently also part
of the backbone providing Internet services, and is therefore of the backbone providing Internet services, and is therefore
susceptible to security and denial of service attacks. The PE susceptible to security and denial of service attacks. The PE
control plane CPU is vulnerable from this point of view, and it may control plane CPU is vulnerable from this point of view, and it may
impact not only VPN services but also general Internet services if impact not only VPN services but also general Internet services if
not adequately protected. In addition to VPN configuration, if not adequately protected. In addition to VPN configuration, if
mechanisms such as QoS are provisioned on the PE, it is possible for mechanisms such as QoS are provisioned on the PE, it is possible for
attackers to recognize the highest priority traffic or customers and attackers to recognize the highest priority traffic or customers and
launch directed attacks. Care should be taken to prevent such launch directed attacks. Care SHOULD be taken to prevent such
attacks whenever any value added services such as QoS are offered. attacks whenever any value added services such as QoS are offered.
When a service such as "Dynamic Bandwidth Management" as described in When a service such as "Dynamic Bandwidth Management" as described in
Section 5.2.1 is provided, it allows customers to dynamically request Section 5.2.1 is provided, it allows customers to dynamically request
for changes to their bandwidth allocation. The provider must take for changes to their bandwidth allocation. The provider MUST take
care to authenticate such requests and detect and prevent possible care to authenticate such requests and detect and prevent possible
Denial-of-Service attacks. These DoS attacks are possible when a Denial-of-Service attacks. These DoS attacks are possible when a
customer maliciously or accidentally may cause a change in bandwidth customer maliciously or accidentally may cause a change in bandwidth
allocation that may impact the bandwidth allocated to other VPN allocation that may impact the bandwidth allocated to other VPN
customers or Internet users. customers or Internet users.
Different choices of VPN technology have different assurance levels Different choices of VPN technology have different assurance levels
of the privacy of a customer's network. For example, CE-based of the privacy of a customer's network. For example, CE-based
solutions may enjoy more privacy than PE-based VPNs by virtue of solutions may enjoy more privacy than PE-based VPNs by virtue of
tunnels extending from CE to CE, even if the tunnels are not tunnels extending from CE to CE, even if the tunnels are not
encrypted. In a PE-based VPN, a PE has many more sites than those encrypted. In a PE-based VPN, a PE has many more sites than those
attached to a CE in a CE-based VPN. A large number of these sites may attached to a CE in a CE-based VPN. A large number of these sites may
use RFC 1918 addresses. Provisioning mistakes and PE software bugs use RFC 1918 addresses. Provisioning mistakes and PE software bugs
may make traffic more prone to being misdirected as opposed to a CE- may make traffic more prone to being misdirected as opposed to a CE-
based VPN. Care must be taken to prevent misconfiguration in all based VPN. Care MUST be taken to prevent misconfiguration in all
kinds of PPVPNs, but more care must be taken in the case of PE-based kinds of PPVPNs, but more care MUST be taken in the case of PE-based
VPNs, as this could impact other customers and Internet services. VPNs, as this could impact other customers and Internet services.
Similarly, there should be mechanisms to prevent the flooding of Similarly, there SHOULD be mechanisms to prevent the flooding of
Internet routing tables whenever there is a misconfiguration or Internet routing tables whenever there is a misconfiguration or
failure of PPVPN control mechanisms that use Internet routing failure of PPVPN control mechanisms that use Internet routing
protocols for relay of VPN-specific information. protocols for relay of VPN-specific information.
Different deployment scenarios also dictate the level of security Different deployment scenarios also dictate the level of security
that may be needed for a VPN. For example, it is easier to control that may be needed for a VPN. For example, it is easier to control
security in a single provider, single AS VPN and therefore, expensive security in a single provider, single AS VPN and therefore, expensive
encryption techniques may not be used in this case, as long as VPN encryption techniques may not be used in this case, as long as VPN
traffic is isolated from the Internet. There is a reasonable amount traffic is isolated from the Internet. There is a reasonable amount
of control possible in the single provider, multi AS case, although of control possible in the single provider, multi AS case, although
care should be taken to ensure the constrained distribution of VPN care SHOULD be taken to ensure the constrained distribution of VPN
route information across the ASes. Security is more of a challenge route information across the ASes. Security is more of a challenge
in the multi-provider case, where it may be necessary to adopt in the multi-provider case, where it may be necessary to adopt
encryption techniques in order to provide the highest level of encryption techniques in order to provide the highest level of
security. security.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process - Revision [RFC2026] Bradner, S., "The Internet Standards Process - Revision
skipping to change at page 25, line 27 skipping to change at page 25, line 27
Provisioned Virtual Private Networks", Provisioned Virtual Private Networks",
<draft-ietf-l3vpn-terminology>, work in progress. <draft-ietf-l3vpn-terminology>, work in progress.
[L3FRAMEWORK] Callon, R., Suzuki, M., et al. "A Framework for [L3FRAMEWORK] Callon, R., Suzuki, M., et al. "A Framework for
Layer 3 Provider Provisioned Virtual Private Networks", Layer 3 Provider Provisioned Virtual Private Networks",
<draft-ietf-l3vpn-framework>, work in progress. <draft-ietf-l3vpn-framework>, work in progress.
[L2FRAMEWORK] Andersson, L., et al. "A Framework for Layer 2 Provider [L2FRAMEWORK] Andersson, L., et al. "A Framework for Layer 2 Provider
Provisioned Virtual Private Networks", Provisioned Virtual Private Networks",
<draft-ietf-l2vpn-l2-framework>, work in progress. <draft-ietf-l2vpn-l2-framework>, work in progress.
[L3REQTS] Carugi, M., McDysan, D. et al., "Service Requirements [L3REQTS] Carugi, M., McDysan, D. et al., "Service Requirements
for Layer 3 Provider Provisioned Virtual Private for Layer 3 Provider Provisioned Virtual Private
Networks", <draft-ietf-l3vpn-requirements>, Networks", <draft-ietf-l3vpn-requirements>, work in progress.
work in progress.
[L2REQTS] Augustyn, W., Serbest, Y., et al., "Service Requirements [L2REQTS] Augustyn, W., Serbest, Y., et al., "Service Requirements
for Layer 2 Provider Provisioned Virtual Private for Layer 2 Provider Provisioned Virtual Private
Networks", <draft-ietf-l2vpn-requirements>, Networks", <draft-ietf-l2vpn-requirements>, work in progress.
work in progress.
[Y.1241] "IP Transfer Capability for the support of IP based [Y.1241] "IP Transfer Capability for the support of IP based
Services", Y.1241 ITU-T Draft Recommendation, March 2000. Services", Y.1241 ITU-T Draft Recommendation, March 2000.
[Y.1311] Knightson, K. (editor), "Network based IP VPN Service [Y.1311] Knightson, K. (editor), "Network based IP VPN Service
- Generic Framework and Service Requirements ", Y.1311 - Generic Framework and Service Requirements ", Y.1311
ITU-T Recommendation, January, 2002. ITU-T Recommendation, January, 2002.
[RFC 3198] A. Westerinen et al, "Terminology for Policy-Based [RFC 3198] A. Westerinen et al, "Terminology for Policy-Based
Management," November, 2001. Management," November, 2001.
[VPN SEC] L. Fang et al, "Security Framework for Provider Provisioned [VPN SEC] L. Fang et al, "Security Framework for Provider Provisioned
Virtual Private Networks," Virtual Private Networks,"
<draft-ietf-l3vpn-security-framework>, work in progress. <draft-ietf-l3vpn-security-framework>, work in progress.
 End of changes. 115 change blocks. 
185 lines changed or deleted 182 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/