< draft-ietf-l3vpn-requirements-01.txt   draft-ietf-l3vpn-requirements-02.txt >
INTERNET DRAFT M. Carugi INTERNET DRAFT M. Carugi
Internet Engineering Task Force Nortel Networks Internet Engineering Task Force Nortel Networks
Document: D. McDysan Document: D. McDysan
draft-ietf-l3vpn-requirements-01.txt MCI draft-ietf-l3vpn-requirements-02.txt MCI
June 2004 (Co-Editors) July 2004 (Co-Editors)
Category: Informational Category: Informational
Expires: December 2004 Expires: January 2005
Service requirements for Layer 3 Virtual Private Networks: Service requirements for Layer 3 Virtual Private Networks:
<draft-ietf-l3vpn-requirements-01.txt> <draft-ietf-l3vpn-requirements-02.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 ([RFC-2026]). all provisions of Section 10 of RFC 2026 ([RFC-2026]).
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 55 skipping to change at line 54
Networks (L3VPNs). It identifies requirements applicable to a number Networks (L3VPNs). It identifies requirements applicable to a number
of individual approaches that a Service Provider may use for the of individual approaches that a Service Provider may use for the
provisioning of a VPN service. This document expresses a service provisioning of a VPN service. This document expresses a service
provider perspective, based upon past experience of IP-based service provider perspective, based upon past experience of IP-based service
offerings and the ever-evolving needs of the customers of such offerings and the ever-evolving needs of the customers of such
services. Toward this end, it first defines terminology and states services. Toward this end, it first defines terminology and states
general requirements. Detailed requirements are expressed from a general requirements. Detailed requirements are expressed from a
customer as well as a service provider perspective. customer as well as a service provider perspective.
Carugi, McDysan et al 1 Carugi, McDysan et al 1
Service requirements for Layer 3 PPVPNs July 2004
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 ([RFC- this document are to be interpreted as described in RFC 2119 ([RFC-
2119]). 2119]).
Table of Contents Table of Contents
1 Introduction....................................................5 1 Introduction....................................................5
1.1 Scope of this document.........................................5 1.1 Scope of this document.........................................5
skipping to change at line 108 skipping to change at line 110
5.10 Migration Impact..............................................19 5.10 Migration Impact..............................................19
5.11 Network Access................................................19 5.11 Network Access................................................19
5.11.1 Physical/Link Layer Technology...........................19 5.11.1 Physical/Link Layer Technology...........................19
5.11.2 Temporary Access.........................................19 5.11.2 Temporary Access.........................................19
5.11.3 Sharing of the Access Network............................20 5.11.3 Sharing of the Access Network............................20
5.11.4 Access Connectivity......................................20 5.11.4 Access Connectivity......................................20
5.12 Service Access................................................22 5.12 Service Access................................................22
5.12.1 Internet Access..........................................22 5.12.1 Internet Access..........................................22
5.12.2 Hosting, Application Service Provider....................22 5.12.2 Hosting, Application Service Provider....................22
Carugi, McDysan et al Informational - Expires December 2004 2 Carugi, McDysan et al Informational - Expires January 2005 2
Service requirements for Layer 3 PPVPNs July 2004
5.12.3 Other Services...........................................22 5.12.3 Other Services...........................................22
5.13 Hybrid VPN Service Scenarios..................................22 5.13 Hybrid VPN Service Scenarios..................................22
6 Service Provider Network Requirements..........................23 6 Service Provider Network Requirements..........................23
6.1 Scalability...................................................23 6.1 Scalability...................................................23
6.2 Addressing....................................................23 6.2 Addressing....................................................23
6.3 Identifiers...................................................23 6.3 Identifiers...................................................23
6.4 Discovering VPN Related Information...........................24 6.4 Discovering VPN Related Information...........................24
6.5 SLA and SLS Support...........................................24 6.5 SLA and SLS Support...........................................24
6.6 Quality of Service (QoS) and Traffic Engineering..............25 6.6 Quality of Service (QoS) and Traffic Engineering..............25
6.7 Routing.......................................................25 6.7 Routing.......................................................25
skipping to change at line 131 skipping to change at line 136
6.9.1 Support for Securing Customer Flows......................26 6.9.1 Support for Securing Customer Flows......................26
6.9.2 Authentication Services..................................27 6.9.2 Authentication Services..................................27
6.9.3 Resource Protection......................................27 6.9.3 Resource Protection......................................27
6.10 Inter-AS (SP)VPNs.............................................28 6.10 Inter-AS (SP)VPNs.............................................28
6.10.1 Routing Protocols........................................28 6.10.1 Routing Protocols........................................28
6.10.2 Management...............................................28 6.10.2 Management...............................................28
6.10.3 Bandwidth and QoS Brokering..............................29 6.10.3 Bandwidth and QoS Brokering..............................29
6.10.4 Security Considerations..................................29 6.10.4 Security Considerations..................................29
6.11 L3VPN Wholesale...............................................29 6.11 L3VPN Wholesale...............................................29
6.12 Tunneling Requirements........................................30 6.12 Tunneling Requirements........................................30
6.13 Support for Access and Backbone Technologies..................31 6.13 Support for Access and Backbone Technologies..................30
6.13.1 Dedicated Access Networks................................31 6.13.1 Dedicated Access Networks................................31
6.13.2 On-Demand Access Networks................................31 6.13.2 On-Demand Access Networks................................31
6.13.3 Backbone Networks........................................31 6.13.3 Backbone Networks........................................31
6.14 Protection, Restoration.......................................31 6.14 Protection, Restoration.......................................31
6.15 Interoperability..............................................32 6.15 Interoperability..............................................32
6.16 Migration Support.............................................32 6.16 Migration Support.............................................32
7 Service Provider Management Requirements.......................33 7 Service Provider Management Requirements.......................33
7.1 Fault management..............................................33 7.1 Fault management..............................................33
7.2 Configuration Management......................................34 7.2 Configuration Management......................................34
7.2.1 Configuration Management for PE-Based VPNs...............35 7.2.1 Configuration Management for PE-Based VPNs...............35
7.2.2 Configuration management for CE-based VPN................35 7.2.2 Configuration management for CE-based VPN................35
7.2.3 Provisioning Routing.....................................36 7.2.3 Provisioning Routing.....................................35
7.2.4 Provisioning Network Access..............................36 7.2.4 Provisioning Network Access..............................35
7.2.5 Provisioning Security Services...........................36 7.2.5 Provisioning Security Services...........................36
7.2.6 Provisioning VPN Resource Parameters.....................36 7.2.6 Provisioning VPN Resource Parameters.....................36
7.2.7 Provisioning Value-Added Service Access..................36 7.2.7 Provisioning Value-Added Service Access..................36
7.2.8 Provisioning Hybrid VPN Services.........................37 7.2.8 Provisioning Hybrid VPN Services.........................37
7.3 Accounting....................................................37 7.3 Accounting....................................................37
7.4 Performance Management........................................38 7.4 Performance Management........................................38
7.4.1 Performance Monitoring...................................38 7.4.1 Performance Monitoring...................................38
7.4.2 SLA and QoS management features..........................38 7.4.2 SLA and QoS management features..........................38
7.5 Security Management...........................................39 7.5 Security Management...........................................38
7.5.1 Resource Access Control....................................39 7.5.1 Resource Access Control....................................38
7.5.2 Authentication...........................................39 7.5.2 Authentication...........................................39
7.6 Network Management Techniques.................................39 7.6 Network Management Techniques.................................39
8 Security Considerations........................................40 8 Security Considerations........................................40
9 Acknowledgements...............................................40 9 Acknowledgements...............................................40
10 References.....................................................41 10 References.....................................................41
10.1 Normative References..........................................41 10.1 Normative References..........................................41
Carugi, McDysan et al Informational - Expires December 2004 3 Carugi, McDysan et al Informational - Expires January 2005 3
10.2 Non-normative References......................................42
Service requirements for Layer 3 PPVPNs July 2004
10.2 Non-normative References......................................41
11 Authors' address...............................................43 11 Authors' address...............................................43
Carugi, McDysan et al Informational - Expires December 2004 4 Carugi, McDysan et al Informational - Expires January 2005 4
Service requirements for Layer 3 PPVPNs July 2004
1 Introduction 1 Introduction
This section describes the scope and outline of the document. This section describes the scope and outline of the document.
1.1 Scope of this document 1.1 Scope of this document
This document provides requirements specific to Layer 3 Virtual This document provides requirements specific to Layer 3 Virtual
Private Networks (L3VPN) (requirements that are generic to L2 and L3 Private Networks (L3VPN) (requirements that are generic to L2 and L3
VPNs are contained in [PPVPN-GR]). VPNs are contained in [PPVPN-GR]).
This document identifies requirements that may apply to one or more This document identifies requirements that may apply to one or more
individual approaches that a Service Provider may use for the individual approaches that a Service Provider may use for the
provisioning of a Layer 3 (e.g., IP) VPN service. It makes use of provisioning of a Layer 3 (e.g., IP) VPN service. It makes use of
skipping to change at line 219 skipping to change at line 230
The following L3VPN deployment scenarios are considered within this The following L3VPN deployment scenarios are considered within this
document: document:
1. Internet-wide: VPN sites attached to arbitrary points in 1. Internet-wide: VPN sites attached to arbitrary points in
the Internet the Internet
2. Single SP/single AS: VPN sites attached to the network of a 2. Single SP/single AS: VPN sites attached to the network of a
single provider within the scope of a single AS single provider within the scope of a single AS
Carugi, McDysan et al Informational - Expires December 2004 5 Carugi, McDysan et al Informational - Expires January 2005 5
3.Single SP/multiple AS'es: VPN sites attached to the network
of a single provider consisting of multiple AS'es Service requirements for Layer 3 PPVPNs July 2004
3.Single SP/multiple ASs: VPN sites attached to the network
of a single provider consisting of multiple ASs
4.Cooperating SPs: VPN sites attached to networks of different 4.Cooperating SPs: VPN sites attached to networks of different
providers that cooperate with each other to provide the VPN providers that cooperate with each other to provide the VPN
service service
The above deployment scenarios have many requirements in common. The above deployment scenarios have many requirements in common.
These common requirements include SP requirements for security, These common requirements include SP requirements for security,
privacy, manageability, interoperability and scalability, including privacy, manageability, interoperability and scalability, including
service provider projections for number, complexity, and rate of service provider projections for number, complexity, and rate of
change of customer VPNs over the next several years. When change of customer VPNs over the next several years. When
skipping to change at line 247 skipping to change at line 261
The outline of the rest of the document is as follows. Section 2 The outline of the rest of the document is as follows. Section 2
mentions the contributing authors. Section 3 provides definitions of mentions the contributing authors. Section 3 provides definitions of
terms and concepts. Section 4 provides requirements that are common terms and concepts. Section 4 provides requirements that are common
to both customers and service providers and are not covered in the to both customers and service providers and are not covered in the
generic provider provisioned VPN requirement document [PPVPN-GR]. generic provider provisioned VPN requirement document [PPVPN-GR].
Section 5 states requirements from a customer perspective. Section 6 Section 5 states requirements from a customer perspective. Section 6
states network requirements from a service provider perspective. states network requirements from a service provider perspective.
Section 7 states service provider management requirements. Section 8 Section 7 states service provider management requirements. Section 8
describes security considerations. Section 9 lists acknowledgements. describes security considerations. Section 9 lists acknowledgements.
Section 10 provides a list of references cited herein. Section 11 Section 10 provides a list of references cited herein. Section 11
lists the authorsÆ addresses. lists the authors' addresses.
2 Contributing Authors 2 Contributing Authors
This document is the combined effort of the two co-editors and the This document is the combined effort of the two co-editors and the
following contributing authors: following contributing authors:
Luyuan Fang Luyuan Fang
Ananth Nagarajan Ananth Nagarajan
Junichi Sumimoto Junichi Sumimoto
Rick Wilder Rick Wilder
3 Definitions 3 Definitions
This section provides the definition of terms and concepts used This section provides the definition of terms and concepts used
throughout the document. Terminology used herein is taken from throughout the document. Terminology used herein is taken from
[PPVPN-TERM] and [L3VPN-FR]. [PPVPN-TERM] and [L3VPN-FR].
3.1 Virtual Private Network 3.1 Virtual Private Network
"L3 Virtual Private Network" (L3 VPN) refers to the L3 communication "L3 Virtual Private Network" (L3 VPN) refers to the L3 communication
between a set of sites, making use of a shared network between a set of sites, making use of a shared network
infrastructure. infrastructure.
ôProvider Provisioned VPNö (PPVPN) refers to VPNs for which the "Provider Provisioned VPN" (PPVPN) refers to VPNs for which the
service provider participates in management and provisioning of the service provider participates in management and provisioning of the
VPN. VPN.
Carugi, McDysan et al Informational - Expires December 2004 6 Carugi, McDysan et al Informational - Expires January 2005 6
Service requirements for Layer 3 PPVPNs July 2004
3.2 Users, Sites, Customers and Agents 3.2 Users, Sites, Customers and Agents
User: A user is an entity (e.g., a human being using a host, a User: A user is an entity (e.g., a human being using a host, a
server, or a system) that has been authorized to use a VPN service. server, or a system) that has been authorized to use a VPN service.
Site: A site is a set of users that have mutual L3 (i.e., IP) Site: A site is a set of users that have mutual L3 (i.e., IP)
reachability without use of a specific service provider network. A reachability without use of a specific service provider network. A
site may consist of a set of users that are in geographic proximity. site may consist of a set of users that are in geographic proximity.
Note that a topological definition of a site (e.g., all users at a Note that a topological definition of a site (e.g., all users at a
specific geographic location) may not always conform to this specific geographic location) may not always conform to this
definition. For example, two geographic locations connected via definition. For example, two geographic locations connected via
skipping to change at line 310 skipping to change at line 327
between a set of sites that belong to different customers. In other between a set of sites that belong to different customers. In other
words, two or more organizations have access to a specified set of words, two or more organizations have access to a specified set of
each other's sites. Examples of an extranet scenario include each other's sites. Examples of an extranet scenario include
multiple companies cooperating in joint software development, a multiple companies cooperating in joint software development, a
service provider having access to information from the vendors' service provider having access to information from the vendors'
corporate sites, different companies, or universities participating corporate sites, different companies, or universities participating
in a consortium. An extranet often has further restrictions on in a consortium. An extranet often has further restrictions on
reachability, for example, at a host and individual transport level. reachability, for example, at a host and individual transport level.
Note that an intranet or extranet can exist across a single service Note that an intranet or extranet can exist across a single service
provider network with one or more ASÆs, or across multiple service provider network with one or more ASs, or across multiple service
provider networks. provider networks.
L3 Virtual Private Network (L3 VPN): An alternative definition of L3 Virtual Private Network (L3 VPN): An alternative definition of
VPN refers to a specific set of sites as either an intranet or an VPN refers to a specific set of sites as either an intranet or an
extranet that have been configured to allow communication. Note that extranet that have been configured to allow communication. Note that
a site is a member of at least one VPN, and may be a member of many a site is a member of at least one VPN, and may be a member of many
VPNs. VPNs.
3.4 Networks of Customer and Provider Devices 3.4 Networks of Customer and Provider Devices
L3VPNs are composed of the following types of devices. L3VPNs are composed of the following types of devices.
Customer Edge (CE) device: A CE device faces the users at a customer Customer Edge (CE) device: A CE device faces the users at a customer
site. The CE has an access connection to a PE device. It may be a site. The CE has an access connection to a PE device. It may be a
Carugi, McDysan et al Informational - Expires December 2004 7 Carugi, McDysan et al Informational - Expires January 2005 7
Service requirements for Layer 3 PPVPNs July 2004
router or a switch that allows users at a customer site to router or a switch that allows users at a customer site to
communicate over the access network with other sites in the VPN. In communicate over the access network with other sites in the VPN. In
a CE-based L3VPN, as intended in this document (provider provisioned a CE-based L3VPN, as intended in this document (provider provisioned
CE-based VPN), the service provider manages (at least partially) the CE-based VPN), the service provider manages (at least partially) the
CE device. CE device.
Provider Edge (PE) device: A PE device faces the provider network on Provider Edge (PE) device: A PE device faces the provider network on
one side and attaches via an access connection over one or more one side and attaches via an access connection over one or more
access networks to one or more CE devices. It participates in the access networks to one or more CE devices. It participates in the
Packet Switched Network (PSN) in performing routing and forwarding Packet Switched Network (PSN) in performing routing and forwarding
skipping to change at line 352 skipping to change at line 372
Provider (P) device: A device within a provider network that Provider (P) device: A device within a provider network that
interconnects PE (or other P) devices, but does not have any direct interconnects PE (or other P) devices, but does not have any direct
attachment to CE devices. The P router does not keep VPN state and attachment to CE devices. The P router does not keep VPN state and
is VPN un-aware [PPVPN-TERM]. is VPN un-aware [PPVPN-TERM].
Packet Switched Network (PSN): A (IP or MPLS) network through which Packet Switched Network (PSN): A (IP or MPLS) network through which
the tunnels supporting the VPN services are set up [PPVPN-TERM]. the tunnels supporting the VPN services are set up [PPVPN-TERM].
Service Provider (SP) network: An SP network is a set of Service Provider (SP) network: An SP network is a set of
interconnected PE and P devices administered by a single service interconnected PE and P devices administered by a single service
provider in one or more ASÆs. provider in one or more ASs.
3.5 Access Networks, Tunnels, and Hierarchical Tunnels 3.5 Access Networks, Tunnels, and Hierarchical Tunnels
VPNs are built between CEs using access networks, tunnels, and VPNs are built between CEs using access networks, tunnels, and
hierarchical tunnels across a PSN. hierarchical tunnels across a PSN.
Access connection: An access connection provides connectivity Access connection: An access connection provides connectivity
between a CE and a PE. This includes dedicated physical circuits, between a CE and a PE. This includes dedicated physical circuits,
virtual circuits, such as Frame Relay, ATM, Ethernet (V)LAN, or IP virtual circuits, such as Frame Relay, ATM, Ethernet (V)LAN, or IP
tunnels (e.g., IPsec, L2TP). tunnels (e.g., IPsec, L2TP).
skipping to change at line 378 skipping to change at line 398
Tunnel: A tunnel between two entities is formed by encapsulating Tunnel: A tunnel between two entities is formed by encapsulating
packets within another encapsulating header for purpose of packets within another encapsulating header for purpose of
transmission between those two entities in support of a VPN transmission between those two entities in support of a VPN
application. Examples of protocols commonly used for tunneling are: application. Examples of protocols commonly used for tunneling are:
GRE, IPsec, IP-in-IP tunnels, and MPLS. GRE, IPsec, IP-in-IP tunnels, and MPLS.
Hierarchical Tunnel: Encapsulating one tunnel within another forms a Hierarchical Tunnel: Encapsulating one tunnel within another forms a
hierarchical tunnel. The innermost tunnel protocol header defines a hierarchical tunnel. The innermost tunnel protocol header defines a
logical association between two entities (e.g., between CEs or PEs) logical association between two entities (e.g., between CEs or PEs)
Carugi, McDysan et al Informational - Expires December 2004 8 Carugi, McDysan et al Informational - Expires January 2005 8
Service requirements for Layer 3 PPVPNs July 2004
[VPN TUNNEL]. Note that the tunneling protocols need not be the same [VPN TUNNEL]. Note that the tunneling protocols need not be the same
at different levels in a hierarchical tunnel. at different levels in a hierarchical tunnel.
3.6 Use of Tunnels and roles of CE and PE in L3 VPNs 3.6 Use of Tunnels and roles of CE and PE in L3 VPNs
This section summarizes the point where tunnels terminate and the This section summarizes the point where tunnels terminate and the
functions implemented in the CE and PE devices that differentiate functions implemented in the CE and PE devices that differentiate
the two major categories of L3 VPNs for which requirements are the two major categories of L3 VPNs for which requirements are
stated, namely PE-based and CE-based L3 VPNs. See the L3VPN stated, namely PE-based and CE-based L3 VPNs. See the L3VPN
framework document for more detail [L3VPN-FR]. framework document for more detail [L3VPN-FR].
skipping to change at line 433 skipping to change at line 455
+-----+ | +------+ | | +------+ | +-----+ +-----+ | +------+ | | +------+ | +-----+
| | | | | | | |
+-----+ Access | +------+ | | +------+ | Access +-----+ +-----+ Access | +------+ | | +------+ | Access +-----+
|CE | conn. | |VFI of| | Tunnel | |VFI of| | conn. | CE | |CE | conn. | |VFI of| | Tunnel | |VFI of| | conn. | CE |
| dev |----------|VPN B |==================|VPN B |----------| dev | | dev |----------|VPN B |==================|VPN B |----------| dev |
| of | | +------+ | | +------+ | | of | | of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B| |VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+ +-----+ +----------+ +----------+ +-----+
Figure 3.1 PE Usage of Separate Tunnels to Support VPNs Figure 3.1 PE Usage of Separate Tunnels to Support VPNs
Carugi, McDysan et al Informational - Expires December 2004 9 Carugi, McDysan et al Informational - Expires January 2005 9
Service requirements for Layer 3 PPVPNs July 2004
Figure 3.2 illustrates the case where a single hierarchical tunnel Figure 3.2 illustrates the case where a single hierarchical tunnel
is used between PE devices to support communication for VPNs. The is used between PE devices to support communication for VPNs. The
innermost encapsulating protocol header provides the means for the innermost encapsulating protocol header provides the means for the
PE to determine the VPN for which the packet is directed. PE to determine the VPN for which the packet is directed.
+----------+ +----------+ +----------+ +----------+
+-----+ |PE device | |PE device | +-----+ +-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE | | CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev | | dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | | |VFI of| | conn. | of | | of | conn. | |VFI of| | | |VFI of| | conn. | of |
|VPN A|----------|VPN A | | Hierarchical | |VPN A |----------|VPN A| |VPN A|----------|VPN A | | Hierarchical | |VPN A |----------|VPN A|
skipping to change at line 469 skipping to change at line 494
site and therefore the forwarding and routing is physically separate site and therefore the forwarding and routing is physically separate
from all other customers. Furthermore, the PE is not aware of the from all other customers. Furthermore, the PE is not aware of the
membership of specific CE devices to a particular VPN. Hence, the membership of specific CE devices to a particular VPN. Hence, the
VPN functions are implemented using provisioned configurations on VPN functions are implemented using provisioned configurations on
the CE devices and the shared PE and P network is used to only the CE devices and the shared PE and P network is used to only
provide the routing and forwarding that supports the tunnel provide the routing and forwarding that supports the tunnel
endpoints on between CE devices. The tunnel topology connecting the endpoints on between CE devices. The tunnel topology connecting the
CE devices may be a full or partial mesh, depending upon VPN CE devices may be a full or partial mesh, depending upon VPN
customer requirements and traffic patterns. customer requirements and traffic patterns.
Carugi, McDysan et al Informational - Expires December 2004 10 Carugi, McDysan et al Informational - Expires January 2005 10
Service requirements for Layer 3 PPVPNs July 2004
+---------+ +--------------------------------+ +---------+ +---------+ +--------------------------------+ +---------+
| | | | | | | | | | | |
| | | +------+ +------+ : +------+ | | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE | +------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device| | CE | : | | | P | | PE | : |device|
|device| : +------+ Tunnel |router| |device| : | of | |device| : +------+ Tunnel |router| |device| : | of |
| of |=:================================================:=|VPN A| | of |=:================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+ |VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : | +------+ : | PE | | | : |
+------+ : |device| | | : | +------+ : |device| | | : |
skipping to change at line 502 skipping to change at line 530
| network | | | | network | | network | | | | network |
Figure 3.3 CE-based L3 VPN Figure 3.3 CE-based L3 VPN
3.7 Customer and Provider Network Management 3.7 Customer and Provider Network Management
Customer Network Management Function: A customer network management Customer Network Management Function: A customer network management
function provides the means for a customer agent to query or function provides the means for a customer agent to query or
configure customer specific information, or receive alarms regarding configure customer specific information, or receive alarms regarding
his or her VPN. Customer specific information includes data related his or her VPN. Customer specific information includes data related
to contact, billing, site, access network, IP address, routing to contact, billing, site, access network, IP address, routing
protocol parameters, etc. It may also include confidential data, protocol parameters, etc. It may use a combination of proprietary
such as encryption keys. It may use a combination of proprietary
network management system, SNMP manager, or directory service (e.g., network management system, SNMP manager, or directory service (e.g.,
LDAP [RFC3377] [RFC2251]). LDAP [RFC3377] [RFC2251]).
Provider Network Management Function: A provider network management Provider Network Management Function: A provider network management
function provides many of the same capabilities as a customer function provides many of the same capabilities as a customer
network management system across all customers. This would not network management system across all customers. This would not
include customer confidential information, such as keying material. include customer confidential information, such as keying material.
The intent of giving the provider a view comparable to that of the The intent of giving the provider a view comparable to that of the
customer is to aid in troubleshooting and problem resolution. Such a customer is to aid in troubleshooting and problem resolution. Such a
system also provides the means to query, configure, or receive system also provides the means to query, configure, or receive
alarms regarding any infrastructure supporting the L3VPN service. It alarms regarding any infrastructure supporting the L3VPN service. It
may use a combination of proprietary network management system, SNMP may use a combination of proprietary network management system, SNMP
manager, or directory service (e.g., LDAP [RFC3377] [RFC2251]). manager, or directory service (e.g., LDAP [RFC3377] [RFC2251]).
Carugi, McDysan et al Informational - Expires December 2004 11 Carugi, McDysan et al Informational - Expires January 2005 11
Service requirements for Layer 3 PPVPNs July 2004
4 Service Requirements Common to Customers and Service Providers 4 Service Requirements Common to Customers and Service Providers
Many of the requirements that apply to both the customer and the Many of the requirements that apply to both the customer and the
provider and are of an otherwise general nature, or apply to both L2 provider and are of an otherwise general nature, or apply to both L2
and L3 VPNs, are described in [PPVPN-GR]. This section contains and L3 VPNs, are described in [PPVPN-GR]. This section contains
requirements specific to L3 VPNs which are not covered in [PPVPN- requirements specific to L3 VPNs which are not covered in [PPVPN-
GR]. GR].
4.1 Isolated Exchange of Data and Routing Information 4.1 Isolated Exchange of Data and Routing Information
A mechanism for isolating the distribution of reachability A mechanism for isolating the distribution of reachability
skipping to change at line 570 skipping to change at line 600
If a customer has private or non-unique IP addresses, then a VPN If a customer has private or non-unique IP addresses, then a VPN
service SHOULD be capable of translating such customer private or service SHOULD be capable of translating such customer private or
non-unique IP addresses for communicating with IP systems having non-unique IP addresses for communicating with IP systems having
public addresses. public addresses.
4.3 Quality of Service 4.3 Quality of Service
To the extent possible, L3 VPN QoS should be independent of the To the extent possible, L3 VPN QoS should be independent of the
access network technology. access network technology.
Carugi, McDysan et al Informational - Expires December 2004 12 Carugi, McDysan et al Informational - Expires January 2005 12
Service requirements for Layer 3 PPVPNs July 2004
4.3.1 QoS Standards 4.3.1 QoS Standards
A non-goal of the L3 VPN WG effort (as chartered) is the development A non-goal of the L3 VPN WG effort (as chartered) is the development
of new protocols or extension of existing ones. With regards to QoS of new protocols or extension of existing ones. With regards to QoS
support, a L3 VPN shall be able to support QoS in one or more of the support, a L3 VPN shall be able to support QoS in one or more of the
following already defined modes: following already defined modes:
- Best Effort (mandatory support for all L3VPN types) - Best Effort (mandatory support for all L3VPN types)
- Aggregate CE Interface Level QoS (ôhoseö level QoS) - Aggregate CE Interface Level QoS ("hose" level QoS)
- Site-to-site (ôpipeö level QoS) - Site-to-site ("pipe" level QoS)
- Intserv (i.e., RSVP) signaled - Intserv (i.e., RSVP) signaled
- Diffserv marked - Diffserv marked
- Across packet-switched access networks - Across packet-switched access networks
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.
L3VPN CEs should be capable of supporting integrated services L3VPN CEs should be capable of supporting integrated services
(Intserv) for certain customers in support of session applications, (Intserv) for certain customers in support of session applications,
such as switched voice or video. Intserv-capable CE devices shall such as switched voice or video. Intserv-capable CE devices shall
skipping to change at line 619 skipping to change at line 652
A CE or PE device supporting a L3 VPN service may classify a packet A CE or PE device supporting a L3 VPN service may classify a packet
for a particular Intserv or Diffserv service based on upon one or for a particular Intserv or Diffserv service based on upon one or
more of the following IP header fields: protocol ID, source port more of the following IP header fields: protocol ID, source port
number, destination port number, destination address, or source number, destination port number, destination address, or source
address. address.
For a specifiable set of Internet traffic, L3 VPN devices should For a specifiable set of Internet traffic, L3 VPN devices should
support Random Early Detection (RED) to provide graceful degradation support Random Early Detection (RED) to provide graceful degradation
in the event of network congestion. in the event of network congestion.
Carugi, McDysan et al Informational - Expires December 2004 13 Carugi, McDysan et al Informational - Expires January 2005 13
Service requirements for Layer 3 PPVPNs July 2004
4.3.2 Service Models 4.3.2 Service Models
A service provider must be able to offer QoS service to a customer A service provider must be able to offer QoS service to a customer
for at least the following generic service types: managed access VPN for at least the following generic service types: managed access VPN
service or edge-to-edge QoS VPN service [PPVPN-GR]. More detail service or edge-to-edge QoS VPN service [PPVPN-GR]. More detail
specific to L3 VPNs is provided below. specific to L3 VPNs is provided below.
A managed access L3 VPN service provides QoS on the access A managed access L3 VPN service provides QoS on the access
connection between the CE and the PE. For example, diffserv would be connection between the CE and the PE. For example, diffserv would be
enabled only on the CE router and the customer-facing ports of the enabled only on the CE router and the customer-facing ports of the
PE router. Note that this service would not require Diffserv PE router. Note that this service would not require Diffserv
skipping to change at line 672 skipping to change at line 708
. A Point-to-Cloud SLS [Y.1311.1], sometimes also referred as . A Point-to-Cloud SLS [Y.1311.1], sometimes also referred as
the "Hose" model, defines traffic parameters in conjunction the "Hose" model, defines traffic parameters in conjunction
with the QoS objectives for traffic exchanged between a CE and with the QoS objectives for traffic exchanged between a CE and
a PE for traffic destined to a set (either all or a subset) of a PE for traffic destined to a set (either all or a subset) of
other sites in the VPN (i.e., the cloud), as applicable. In other sites in the VPN (i.e., the cloud), as applicable. In
other words, a point-to-cloud SLS defines compliance in terms other words, a point-to-cloud SLS defines compliance in terms
of all packets transmitted from a given VPN site toward the SP of all packets transmitted from a given VPN site toward the SP
network on an aggregate basis (i.e., regardless of the network on an aggregate basis (i.e., regardless of the
destination VPN site of each packet). destination VPN site of each packet).
Carugi, McDysan et al Informational - Expires December 2004 14 Carugi, McDysan et al Informational - Expires January 2005 14
Service requirements for Layer 3 PPVPNs July 2004
. A Cloud-to-Point SLS (a case not covered by this SLS is where . A Cloud-to-Point SLS (a case not covered by this SLS is where
flows originating from multiple sources may congest the flows originating from multiple sources may congest the
interface from the network toward a specific site). interface from the network toward a specific site).
Traffic parameters and actions SHOULD be defined for packets to and Traffic parameters and actions SHOULD be defined for packets to and
from the demarcation between the service provider and the site. For from the demarcation between the service provider and the site. For
example, policing may be defined on ingress and shaping on egress. example, policing may be defined on ingress and shaping on egress.
4.5 Management 4.5 Management
An SP and its customers MUST be able to manage the capabilities and An SP and its customers MUST be able to manage the capabilities and
skipping to change at line 722 skipping to change at line 761
service continuity among sites belonging to different portions of service continuity among sites belonging to different portions of
the network. the network.
5 Customer Requirements 5 Customer Requirements
This section captures additional requirements from a customer This section captures additional requirements from a customer
perspective. perspective.
5.1 VPN Membership (Intranet/Extranet) 5.1 VPN Membership (Intranet/Extranet)
When an extranet is formed, a customer agent from each of the When an extranet is formed, a customer agent from each of the
organizations first approves addition of a site to an extranet VPN organizations first approves addition of a site to an extranet VPN
as a business decision between the parties involved. When one or as a business decision between the parties involved. The solution
more SPs are involved, the solution SHALL allow SPs to ensure that SHOULD provide a means such that these organizations can control
Carugi, McDysan et al Informational - Expires December 2004 15 Carugi, McDysan et al Informational - Expires January 2005 15
both organizations approve extranet communication before the L3VPN
allows exchange of traffic and routing information. Service requirements for Layer 3 PPVPNs July 2004
extranet communication involving the L3VPN exchange of traffic and
routing information.
5.2 Service Provider Independence 5.2 Service Provider Independence
Customers MAY require VPN service that spans multiple administrative Customers MAY require VPN service that spans multiple administrative
domains or service provider networks. Therefore, a VPN service MUST domains or service provider networks. Therefore, a VPN service MUST
be able to span multiple AS and SP networks, but still act and be able to span multiple AS and SP networks, but still act and
appear as a single, homogenous VPN from a customer point of view. appear as a single, homogenous VPN from a customer point of view.
A customer might also start with a VPN provided in a single AS with A customer might also start with a VPN provided in a single AS with
a certain SLA but then ask for an expansion of the service spanning a certain SLA but then ask for an expansion of the service spanning
multiple ASs/SPs. In this case, as well as for all kinds of multi- multiple ASs/SPs. In this case, as well as for all kinds of multi-
skipping to change at line 755 skipping to change at line 797
o globally unique addresses obtained by the customer o globally unique addresses obtained by the customer
o globally unique addresses statically assigned by the L3VPN o globally unique addresses statically assigned by the L3VPN
service provider service provider
o on-demand, dynamically assigned IP addresses (e.g., DHCP), o on-demand, dynamically assigned IP addresses (e.g., DHCP),
irrespective of whether the access is temporary (e.g., remote) or irrespective of whether the access is temporary (e.g., remote) or
permanent (i.e., dedicated) permanent (i.e., dedicated)
In the case of combined L3 VPN service with non-unique or private In the case of combined L3 VPN service with non-unique or private
addresses and Internet access, mechanisms that permit the exchange addresses and Internet access, mechanisms that permit the exchange
of traffic between the customer's address space and the global of traffic between the customer's address space and the global
unique Internet address space MUST be supported, for example NAT. unique Internet address space MAY be supported. For example, NAT is
employed by many customers and some service providers today to meet
this need. A preferred solution would be to assign unique addresses,
either IPv4 or IPv6; however, some customers do not want to renumber
their networks.
5.4 Routing Protocol Support 5.4 Routing Protocol Support
There SHOULD be no restriction on the routing protocols used between There SHOULD be no restriction on the routing protocols used between
CE and PE routers, or between CE routers. At least the following CE and PE routers, or between CE routers. At least the following
protocols MUST be supported: static routing, IGP protocols, such as protocols MUST be supported: static routing, IGP protocols, such as
RIP, OSPF, IS-IS, and BGP [L3VPN-FR]. RIP, OSPF, IS-IS, and BGP [L3VPN-FR].
5.5 Quality of Service and Traffic Parameters 5.5 Quality of Service and Traffic Parameters
QoS is expected to be an important aspect of a L3VPN service for QoS is expected to be an important aspect of a L3VPN service for
some customers. QoS requirements cover scenarios involving an some customers. QoS requirements cover scenarios involving an
intranet, an extranet, as well as shared access between a VPN site intranet, an extranet, as well as shared access between a VPN site
and the Internet. and the Internet.
5.5.1 Application Level QoS Objectives 5.5.1 Application Level QoS Objectives
A customer is concerned primarily that the L3VPN service provide his A customer is concerned primarily that the L3VPN service provide his
or her applications with the QoS and level of traffic such that the or her applications with the QoS and level of traffic such that the
applications perform acceptably. Voice and interactive video, and applications perform acceptably. Voice and interactive video, and
multimedia applications are expected to require the most stringent multimedia applications are expected to require the most stringent
Carugi, McDysan et al Informational - Expires January 2005 16
Service requirements for Layer 3 PPVPNs July 2004
QoS. These real-time applications are sensitive to delay, delay QoS. These real-time applications are sensitive to delay, delay
variation, loss, availability and/or reliability. Another set of variation, loss, availability and/or reliability. Another set of
applications, including some multimedia and interactive video applications, including some multimedia and interactive video
applications, high-performance web browsing and file transfer applications, high-performance web browsing and file transfer
Carugi, McDysan et al Informational - Expires December 2004 16
intensive applications, requires near real time performance. intensive applications, requires near real time performance.
Finally, best effort applications are not sensitive to degradation, Finally, best effort applications are not sensitive to degradation,
that is are elastic and can adapt to conditions of degraded that is are elastic and can adapt to conditions of degraded
performance. performance.
The selection of appropriate QoS and service type to meet specific The selection of appropriate QoS and service type to meet specific
application requirements is particularly important to deal with application requirements is particularly important to deal with
periods of congestion in a SP network. Sensitive applications will periods of congestion in a SP network. Sensitive applications will
likely select per-flow Integrated service (Intserv) with precise SLA likely select per-flow Integrated service (Intserv) with precise SLA
guarantees measured on a per flow basis. On the other hand, non- guarantees measured on a per flow basis. On the other hand, non-
skipping to change at line 814 skipping to change at line 863
egress CE [see section 2.6.2 of RFC 3270 and Y.1311.1]. Although RFC egress CE [see section 2.6.2 of RFC 3270 and Y.1311.1]. Although RFC
2475 states that interior or boundary nodes within a DS domain can 2475 states that interior or boundary nodes within a DS domain can
change the DSCP, customer VPNs MAY have other requirements, such as: change the DSCP, customer VPNs MAY have other requirements, such as:
o Applications that use the DSCP in a manner differently than the o Applications that use the DSCP in a manner differently than the
DSCP solution supported by the SP network(s); DSCP solution supported by the SP network(s);
o Customers using more DSCPs within their sites than the SP o Customers using more DSCPs within their sites than the SP
network(s) supports; network(s) supports;
o Support for a carrier's carrier service where one SP is the o Support for a carrier's carrier service where one SP is the
customer of another L3VPN SP. Such an SP should be able to resell customer of another L3VPN SP. Such an SP should be able to resell
VPN service to his or her VPN customers independently of the DSCP VPN service to his or her VPN customers independently of the DSCP
mapping solution supported by the carrierÆs carrier SP. mapping solution supported by the carrier's carrier SP.
Note that support for DSCP transparency has no implication on the Note that support for DSCP transparency has no implication on the
QoS or SLA requirements. If an SP supports DSCP transparency, then QoS or SLA requirements. If an SP supports DSCP transparency, then
that SP needs to only carry the DSCP values across its domain, but that SP needs to only carry the DSCP values across its domain, but
MAY map the received DSCP to some other value for QoS support across MAY map the received DSCP to some other value for QoS support across
its domain. its domain.
5.6 Service Level Specification/Agreement 5.6 Service Level Specification/Agreement
Most customers simply want their applications to perform well. An Most customers simply want their applications to perform well. An
SLA is a vehicle for customer recourse in the event that SP(s) do SLA is a vehicle for customer recourse in the event that SP(s) do
not perform or manage a VPN service well in a measurable sense. not perform or manage a VPN service well in a measurable sense.
Therefore, when purchasing service under an SLA, a customer agent Therefore, when purchasing service under an SLA, a customer agent
Carugi, McDysan et al Informational - Expires January 2005 17
Service requirements for Layer 3 PPVPNs July 2004
MUST have access to the measures from the SP(s) that support the MUST have access to the measures from the SP(s) that support the
SLA. SLA.
Carugi, McDysan et al Informational - Expires December 2004 17
5.7 Customer Management of a VPN 5.7 Customer Management of a VPN
A customer MUST have a means to view the topology, operational A customer MUST have a means to view the topology, operational
state, order status, and other parameters associated with his or her state, order status, and other parameters associated with his or her
VPN. VPN.
Most aspects of management information about CE devices and customer Most aspects of management information about CE devices and customer
attributes of a L3VPN manageable by an SP SHOULD be capable of being attributes of a L3VPN manageable by an SP SHOULD be capable of being
configured and maintained by an authenticated, authorized customer configured and maintained by an authenticated, authorized customer
agent. However, some aspects, such as encryption keys, SHALL NOT be agent. However, some aspects, such as encryption keys, SHALL NOT be
readable nor writable by management systems. readable nor writable by management systems.
skipping to change at line 875 skipping to change at line 928
Security in a L3VPN service SHOULD be as transparent as possible to Security in a L3VPN service SHOULD be as transparent as possible to
the customer, with the obvious exception of support for remote or the customer, with the obvious exception of support for remote or
temporary user access, as detailed in section 5.11.2. temporary user access, as detailed in section 5.11.2.
L3VPN customers MUST be able to deploy their own internal security L3VPN customers MUST be able to deploy their own internal security
mechanisms in addition to those deployed by the SP, in order to mechanisms in addition to those deployed by the SP, in order to
secure specific applications or traffic at a granularity finer than secure specific applications or traffic at a granularity finer than
a site-to-site basis. a site-to-site basis.
If a a customer requires QoS support in a L3 VPN, then this request If a customer requires QoS support in a L3 VPN, then this request
MUST be communicated to the SP either using unencrypted fields or MUST be communicated to the SP either using unencrypted fields or
else via an agreed security association. For example, applications else via an agreed security association. For example, applications
could send RSVP messages in support of Intserv either in the clear could send RSVP messages in support of Intserv either in the clear
or encrypted using a key negotiated with the SP. Another case is or encrypted using a key negotiated with the SP. Another case is
Carugi, McDysan et al Informational - Expires January 2005 18
Service requirements for Layer 3 PPVPNs July 2004
where applications using an IPsec tunnel could copy the DSCP from where applications using an IPsec tunnel could copy the DSCP from
the encrypted IP header to the header of the tunnelÆs IP header. the encrypted IP header to the header of the tunnel's IP header.
Carugi, McDysan et al Informational - Expires December 2004 18
5.10 Migration Impact 5.10 Migration Impact
Often, customers are migrating from an already deployed private Often, customers are migrating from an already deployed private
network toward one or more L3 VPN solutions. A typical private network toward one or more L3 VPN solutions. A typical private
network scenario is CE routers connected via real or virtual network scenario is CE routers connected via real or virtual
circuits. Ideally, minimal incremental cost SHOULD result during the circuits. Ideally, minimal incremental cost SHOULD result during the
migration period. Furthermore, if necessary, any disruption of migration period. Furthermore, if necessary, any disruption of
service SHOULD also be minimized. service SHOULD also be minimized.
A range of scenarios of customer migration MUST be supported. Full A range of scenarios of customer migration MUST be supported. Full
migration of all sites MUST be supported. Support for cases of migration of all sites MUST be supported. Support for cases of
skipping to change at line 931 skipping to change at line 988
one VPN site : in order to limit access to a VPN to only authorized one VPN site : in order to limit access to a VPN to only authorized
users, it is first necessary to authenticate them. Authentication users, it is first necessary to authenticate them. Authentication
SHALL apply as configured by the customer agent and/or SP where a SHALL apply as configured by the customer agent and/or SP where a
specific user may be part of one or more VPNs. The authentication specific user may be part of one or more VPNs. The authentication
function SHOULD be used to automatically invoke all actions function SHOULD be used to automatically invoke all actions
necessary to join a user to the VPN. necessary to join a user to the VPN.
A user SHOULD be able to access a L3VPN via a network having generic A user SHOULD be able to access a L3VPN via a network having generic
Internet access. Internet access.
Carugi, McDysan et al Informational - Expires January 2005 19
Service requirements for Layer 3 PPVPNs July 2004
Mobile users may move within a L3VPN site. Mobile users may also Mobile users may move within a L3VPN site. Mobile users may also
have temporary connections to different L3VPN site within the same have temporary connections to different L3VPN site within the same
VPN. Authentication SHOULD be provided for both of these cases. VPN. Authentication SHOULD be provided for both of these cases.
Carugi, McDysan et al Informational - Expires December 2004 19
5.11.3 Sharing of the Access Network 5.11.3 Sharing of the Access Network
In a PE-based L3VPN, if the site shares the access network with In a PE-based L3VPN, if the site shares the access network with
other traffic (e.g., access to the Internet), then data security in other traffic (e.g., access to the Internet), then data security in
the access network is the responsibility of the L3VPN customer. the access network is the responsibility of the L3VPN customer.
5.11.4 Access Connectivity 5.11.4 Access Connectivity
Various types of physical connectivity scenarios MUST be supported, Various types of physical connectivity scenarios MUST be supported,
such as multi-homed sites, backdoor links between customer sites, such as multi-homed sites, backdoor links between customer sites,
devices homed to two or more SP networks. L3VPN solutions SHOULD devices homed to two or more SP networks. L3VPN solutions SHOULD
support at least the types of physical or link-layer connectivity support at least the types of physical or link-layer connectivity
skipping to change at line 967 skipping to change at line 1027
For multi-homing to a single SP, load balancing capability SHOULD be For multi-homing to a single SP, load balancing capability SHOULD be
supported by the PE across the CE to PE links. For example, in case supported by the PE across the CE to PE links. For example, in case
(a), load balancing SHOULD be provided by the two PEs over the two (a), load balancing SHOULD be provided by the two PEs over the two
links connecting to the single CE. In case (c), load balancing links connecting to the single CE. In case (c), load balancing
SHOULD be provided by the two PEs over the two links connecting to SHOULD be provided by the two PEs over the two links connecting to
the two CEs. the two CEs.
In addition, the load balancing parameters (e.g., the ratio of In addition, the load balancing parameters (e.g., the ratio of
traffic on the multiple load-balanced links, or the preferred link) traffic on the multiple load-balanced links, or the preferred link)
SHOULD be provisionable based on customerÆs requirements. The load SHOULD be provisionable based on customer's requirements. The load
balancing capability may also be used to achieve resiliency in the balancing capability may also be used to achieve resiliency in the
event of access connectivity failures. For example, in cases (b) a event of access connectivity failures. For example, in cases (b) a
CE may connect to two different SPs via diverse access networks. CE may connect to two different SPs via diverse access networks.
Resiliency MAY be further enhanced as shown in case (d), where CEs Resiliency MAY be further enhanced as shown in case (d), where CEs
connected via a "back door" connection connect to different SPs. connected via a "back door" connection connect to different SPs.
Furthermore, arbitrary combinations of the above methods, with a few Furthermore, arbitrary combinations of the above methods, with a few
examples shown in cases (e) and (f) should be supportable by any examples shown in cases (e) and (f) should be supportable by any
L3VPN approach. L3VPN approach.
For multi-homing to multiple SPs, load balancing capability MAY also For multi-homing to multiple SPs, load balancing capability MAY also
be supported by the PEs in the different SPs (clearly, this is a be supported by the PEs in the different SPs (clearly, this is a
more complex type of load balancing to realize, and requires policy more complex type of load balancing to realize, and requires policy
and service agreements between the SPs to interoperate). and service agreements between the SPs to interoperate).
Carugi, McDysan et al Informational - Expires December 2004 20 Carugi, McDysan et al Informational - Expires January 2005 20
Service requirements for Layer 3 PPVPNs July 2004
+---------------- +--------------- +---------------- +---------------
| | | |
+------+ +------+ +------+ +------+
+---------| PE | +---------| PE | +---------| PE | +---------| PE |
| |router| | |router| SP network | |router| | |router| SP network
| +------+ | +------+ | +------+ | +------+
+------+ | +------+ | +------+ | +------+ |
| CE | | | CE | +--------------- | CE | | | CE | +---------------
|device| | SP network |device| +--------------- |device| | SP network |device| +---------------
+------+ | +------+ | +------+ | +------+ |
skipping to change at line 1036 skipping to change at line 1099
|link \ | |link \ | |link \ | |link \ |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE | | CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network |device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| | | |
+---------------- +--------------- +---------------- +---------------
(e) (f) (e) (f)
Figure 5.1 Representative types of access arrangements. Figure 5.1 Representative types of access arrangements.
Carugi, McDysan et al Informational - Expires December 2004 21 Carugi, McDysan et al Informational - Expires January 2005 21
Service requirements for Layer 3 PPVPNs July 2004
5.12 Service Access 5.12 Service Access
Customers MAY also require access to other services, as described in Customers MAY also require access to other services, as described in
this section. this section.
5.12.1 Internet Access 5.12.1 Internet Access
Customers SHOULD be able to have L3 VPN and Internet access across Customers SHOULD be able to have L3 VPN and Internet access across
the same access network for one or more of the customer's sites. the same access network for one or more of the customer's sites.
Customers SHOULD be able to direct Internet traffic from the set of Customers SHOULD be able to direct Internet traffic from the set of
sites in the L3VPN to one or more customer sites that have sites in the L3VPN to one or more customer sites that have
skipping to change at line 1058 skipping to change at line 1124
all traffic between the Internet and the customer's VPN. all traffic between the Internet and the customer's VPN.
L3 VPN Customers SHOULD be able to receive traffic from the Internet L3 VPN Customers SHOULD be able to receive traffic from the Internet
addressed to a publicly accessible resource that is not part of the addressed to a publicly accessible resource that is not part of the
VPN, such as an enterprise's public web server. VPN, such as an enterprise's public web server.
As stated in section 5.3, if a customer L3 VPN employs private or As stated in section 5.3, if a customer L3 VPN employs private or
non-unique IP addresses, then network address translation (NAT) or a non-unique IP addresses, then network address translation (NAT) or a
similar mechanism MUST be provided either by the customer or the SP similar mechanism MUST be provided either by the customer or the SP
in order to be able to exchange traffic with devices outside the in order to be able to exchange traffic with devices outside the
customerÆs L3 VPN. customer's L3 VPN.
5.12.2 Hosting, Application Service Provider 5.12.2 Hosting, Application Service Provider
A customer SHOULD be able to access hosting, other application A customer SHOULD be able to access hosting, other application
services, or other Application Service Providers (ASP) over a L3 services, or other Application Service Providers (ASP) over a L3
L3VPN service. This MAY require that an ASP participates in one or L3VPN service. This MAY require that an ASP participates in one or
more VPNs with the customers that use such a service. more VPNs with the customers that use such a service.
5.12.3 Other Services 5.12.3 Other Services
In conjunction with a VPN service, a customer MAY also wish to have In conjunction with a VPN service, a customer MAY also wish to have
access to other services, such as: DNS, FTP, HTTP, NNTP, SMTP, LDAP, access to other services, such as: DNS, FTP, HTTP, NNTP, SMTP, LDAP,
skipping to change at line 1087 skipping to change at line 1153
Intranet or extranet customers have a number of reasons for wanting Intranet or extranet customers have a number of reasons for wanting
hybrid networks that involve more than one VPN solution type. These hybrid networks that involve more than one VPN solution type. These
include migration, mergers, extranet customers with different VPN include migration, mergers, extranet customers with different VPN
types, the need for different capabilities between different sets of types, the need for different capabilities between different sets of
sites, temporary access, different availability of VPN solutions as sites, temporary access, different availability of VPN solutions as
provided by different service providers. provided by different service providers.
The framework and solution approaches SHOULD include provisions for The framework and solution approaches SHOULD include provisions for
interworking, interconnection, and/or reachability between different interworking, interconnection, and/or reachability between different
Carugi, McDysan et al Informational - Expires December 2004 22 Carugi, McDysan et al Informational - Expires January 2005 22
Service requirements for Layer 3 PPVPNs July 2004
L3VPN solutions in such a way that does not overly complicate L3VPN solutions in such a way that does not overly complicate
provisioning, management, scalability, or performance. provisioning, management, scalability, or performance.
6 Service Provider Network Requirements 6 Service Provider Network Requirements
This section describes requirements from a service provider This section describes requirements from a service provider
perspective. perspective.
6.1 Scalability 6.1 Scalability
[PPVPN-GR} lists projections regarding L3VPN sizing and scalability [PPVPN-GR} lists projections regarding L3VPN sizing and scalability
requirements and metrics related to specific solutions. requirements and metrics related to specific solutions.
skipping to change at line 1140 skipping to change at line 1209
SP's network. Ideally, the VPN identifier SHOULD be globally unique SP's network. Ideally, the VPN identifier SHOULD be globally unique
to support the case where a VPN spans multiple SPs (e.g., [RFC to support the case where a VPN spans multiple SPs (e.g., [RFC
2685]). 2685]).
A CE device SHOULD have a unique identifier, at least within each A CE device SHOULD have a unique identifier, at least within each
SP's network. SP's network.
A PE device SHOULD have a unique identifier, at least within each A PE device SHOULD have a unique identifier, at least within each
SP's network. SP's network.
Carugi, McDysan et al Informational - Expires December 2004 23 Carugi, McDysan et al Informational - Expires January 2005 23
Service requirements for Layer 3 PPVPNs July 2004
The identifier of a device interconnecting SP networks MUST be The identifier of a device interconnecting SP networks MUST be
unique within the set of aforementioned networks. unique within the set of aforementioned networks.
Each site interface SHOULD have a unique identifier, at least within Each site interface SHOULD have a unique identifier, at least within
each PE router supporting such an interface. each PE router supporting such an interface.
Each tunnel SHOULD have a unique identifier, at least within each Each tunnel SHOULD have a unique identifier, at least within each
router supporting the tunnel. router supporting the tunnel.
6.4 Discovering VPN Related Information 6.4 Discovering VPN Related Information
skipping to change at line 1173 skipping to change at line 1245
information. information.
Each device in a VPN SHOULD be able to determine which other devices Each device in a VPN SHOULD be able to determine which other devices
belong to the same VPN. Such a membership discovery scheme MUST belong to the same VPN. Such a membership discovery scheme MUST
prevent unauthorized access and allow authentication of the source. prevent unauthorized access and allow authentication of the source.
Distribution of VPN information SHOULD be limited to those devices Distribution of VPN information SHOULD be limited to those devices
involved in that VPN. involved in that VPN.
In the case of a PE-based VPN, a solution SHOULD support the means In the case of a PE-based VPN, a solution SHOULD support the means
for attached CEs to authenticate each other and verify that the SPÆs for attached CEs to authenticate each other and verify that the SP's
VPN network is correctly configured. VPN network is correctly configured.
The mechanism SHOULD respond to VPN membership changes in a timely The mechanism SHOULD respond to VPN membership changes in a timely
manner. A "timely manner" is no longer than the provisioning manner. A "timely manner" is no longer than the provisioning
timeframe, typically on the order of minutes, and could be as short timeframe, typically on the order of minutes, and could be as short
as the timeframe required for "rerouting," typically on the order of as the timeframe required for "rerouting," typically on the order of
seconds. seconds.
Dynamically creating, changing, and managing multiple VPN Dynamically creating, changing, and managing multiple VPN
assignments to sites and/or customers is another aspect of assignments to sites and/or customers is another aspect of
membership that MUST be addressed in a L3 VPN solution. membership that MUST be addressed in a L3 VPN solution.
6.5 SLA and SLS Support 6.5 SLA and SLS Support
Typically, a Service Provider offering a L3VPN service commits to Typically, a Service Provider offering a L3VPN service commits to
specific Service Level Specifications (SLS) as part of a contract specific Service Level Specifications (SLS) as part of a contract
with the customer, as described in section 4.4 and [PPVPN-GR]. Such with the customer, as described in section 4.4 and [PPVPN-GR]. Such
a Service Level Agreement (SLA) implies SP requirements for a Service Level Agreement (SLA) implies SP requirements for
measuring Specific Service Level Specifications (SLS) for quality, measuring Specific Service Level Specifications (SLS) for quality,
availability, response time, and configuration intervals. availability, response time, and configuration intervals.
Carugi, McDysan et al Informational - Expires December 2004 24 Carugi, McDysan et al Informational - Expires January 2005 24
Service requirements for Layer 3 PPVPNs July 2004
6.6 Quality of Service (QoS) and Traffic Engineering 6.6 Quality of Service (QoS) and Traffic Engineering
A significant aspect of a L3VPN is support for QoS. Since an SP has A significant aspect of a L3VPN is support for QoS. Since an SP has
control over the provisioning of resources and configuration of control over the provisioning of resources and configuration of
parameters in at least the PE and P devices, and in some cases, the parameters in at least the PE and P devices, and in some cases, the
CE device as well, the onus is on the SP to provide either managed CE device as well, the onus is on the SP to provide either managed
QoS access service, or edge-to-edge QoS service, as defined in QoS access service, or edge-to-edge QoS service, as defined in
section 4.3.2. section 4.3.2.
Each L3VPN approach MUST describe the traffic engineering techniques Each L3VPN approach MUST describe the traffic engineering techniques
available for a SP to meet the QoS objectives. These descriptions of available for a SP to meet the QoS objectives. These descriptions of
skipping to change at line 1246 skipping to change at line 1321
When VPN customers use overlapping, non-unique IP addresses, the When VPN customers use overlapping, non-unique IP addresses, the
solution MUST define a means to distinguish between such overlapping solution MUST define a means to distinguish between such overlapping
addresses on a per-VPN basis. addresses on a per-VPN basis.
Furthermore, the solution SHOULD provide an option that either Furthermore, the solution SHOULD provide an option that either
allows, or prevents advertisement of VPN routes to the Internet. allows, or prevents advertisement of VPN routes to the Internet.
Ideally, the choice of a SP's IGP SHOULD not depend on the routing Ideally, the choice of a SP's IGP SHOULD not depend on the routing
protocol(s) used between PE and CE routers in a PE-based VPN. protocol(s) used between PE and CE routers in a PE-based VPN.
Carugi, McDysan et al Informational - Expires December 2004 25 Carugi, McDysan et al Informational - Expires January 2005 25
Service requirements for Layer 3 PPVPNs July 2004
Furthermore, it is desirable that an SP SHOULD have a choice with Furthermore, it is desirable that an SP SHOULD have a choice with
regards to the IGP routing protocol. regards to the IGP routing protocol.
The additional routing burden that an SP must carry should be The additional routing burden that an SP must carry should be
articulated in each specific L3 VPN solution. articulated in each specific L3 VPN solution.
6.8 Isolation of Traffic and Routing 6.8 Isolation of Traffic and Routing
The internal structure of a L3VPN network SHOULD not be visible to The internal structure of a L3VPN network SHOULD not be visible to
outside networks (i.e., the Internet or any connected VPN). outside networks (i.e., the Internet or any connected VPN).
skipping to change at line 1287 skipping to change at line 1365
6.9.1 Support for Securing Customer Flows 6.9.1 Support for Securing Customer Flows
In order to meet the general requirement for providing a range of In order to meet the general requirement for providing a range of
security options to a customer, each L3VPN solution MUST clearly security options to a customer, each L3VPN solution MUST clearly
spell out the configuration options that can work together and how spell out the configuration options that can work together and how
the can do so. the can do so.
When a VPN solution operates over a part of the Internet, it should When a VPN solution operates over a part of the Internet, it should
support a configurable option to support one or more of the support a configurable option to support one or more of the
following standard IPsec methods for securing a flow for a specified following standard IPsec methods for securing a flow for a specified
subset of a customerÆs VPN traffic: subset of a customer's VPN traffic:
o confidentiality, so that only authorized devices can decrypt it, o confidentiality, so that only authorized devices can decrypt it,
o integrity, to ensure that the data has not been altered, o integrity, to ensure that the data has not been altered,
o authentication, to ensure that the sender is indeed who he or she o authentication, to ensure that the sender is indeed who he or she
claims to be, claims to be,
o replay attack prevention. o replay attack prevention.
The above functions SHOULD be capable of being applied to "data The above functions SHOULD be capable of being applied to "data
traffic" of the customer, which includes the traffic exchanged traffic" of the customer, which includes the traffic exchanged
between sites, between temporary users and sites and even between between sites, between temporary users and sites and even between
temporary users. It SHOULD also be possible to apply these functions temporary users. It SHOULD also be possible to apply these functions
to "control traffic", such as routing protocol exchanges, that are to "control traffic", such as routing protocol exchanges, that are
Carugi, McDysan et al Informational - Expires December 2004 26 Carugi, McDysan et al Informational - Expires January 2005 26
Service requirements for Layer 3 PPVPNs July 2004
not necessarily perceived by the customer but nevertheless essential not necessarily perceived by the customer but nevertheless essential
to maintain his or her VPN. to maintain his or her VPN.
Furthermore, such security methods MUST be configurable between Furthermore, such security methods MUST be configurable between
different end points, such as CE-CE, PE-PE, and CE-PE. It is also different end points, such as CE-CE, PE-PE, and CE-PE. It is also
desirable to configure security on a per-route or per-VPN basis [VPN desirable to configure security on a per-route or per-VPN basis [VPN
SEC]. SEC].
A VPN solution MAY support one or more encryption schemes, including A VPN solution MAY support one or more encryption schemes, including
AES, 3DES. Encryption, decryption, and key management SHOULD be AES, 3DES. Encryption, decryption, and key management SHOULD be
skipping to change at line 1353 skipping to change at line 1434
6.9.3 Resource Protection 6.9.3 Resource Protection
Recall from the definitions in section 3.3, that a site can be part Recall from the definitions in section 3.3, that a site can be part
of an intranet with sites from the only same organization, part of of an intranet with sites from the only same organization, part of
an extranet involving sites from other organizations, have access to an extranet involving sites from other organizations, have access to
the Internet, or any combination of these scopes of communication. the Internet, or any combination of these scopes of communication.
Within these contexts, a site might be subject to various attacks Within these contexts, a site might be subject to various attacks
coming from different sources. Potential sources of attack include: coming from different sources. Potential sources of attack include:
- users connected to the supporting public IP backbone, - users connected to the supporting public IP backbone,
- users from the Internet, - users from the Internet,
Carugi, McDysan et al Informational - Expires December 2004 27 Carugi, McDysan et al Informational - Expires January 2005 27
Service requirements for Layer 3 PPVPNs July 2004
- users from temporary sites belonging to the intranet and/or - users from temporary sites belonging to the intranet and/or
extranet VPN that the site is part of. extranet VPN that the site is part of.
Security threats and risks that a site may encounter include the Security threats and risks that a site may encounter include the
following: following:
- denial of service, for example mail spamming, access connection - denial of service, for example mail spamming, access connection
congestion, TCP SYN attacks, ping attacks, etc. congestion, TCP SYN attacks, ping attacks, etc.
- intrusion attempts, which may eventually lead to denial of - intrusion attempts, which may eventually lead to denial of
service (e.g. a Trojan horse attack). service (e.g. a Trojan horse attack).
Additional threat scenarios are defined in [VPNSEC]. A L3 VPN Additional threat scenarios are defined in [VPNSEC]. A L3 VPN
solution MUST state how it addresses each potential threat scenario. solution MUST state how it addresses each potential threat scenario.
The devices in the L3VPN network must provide some means of The devices in the L3VPN network must provide some means of
reporting intrusion attempts to the service provider resources. reporting intrusion attempts to the service provider resources.
6.10 Inter-AS (SP)VPNs 6.10 Inter-AS (SP)VPNs
The scenario for VPNs spanning multiple Autonomous Systems (AS) or The scenario for VPNs spanning multiple Autonomous Systems (AS) or
Service Providers (SP) requires standard solutions. The scenario Service Providers (SP) requires standard solutions. The scenario
where multiple ASÆs are involved is the most general case, and is where multiple ASs are involved is the most general case, and is
therefore the one described here. The scenarios of concern are the therefore the one described here. The scenarios of concern are the
CE-based and PE-based L3 VPNs defined in section 3. CE-based and PE-based L3 VPNs defined in section 3.
In each scenario, all applicable SP requirements, such as traffic In each scenario, all applicable SP requirements, such as traffic
and routing isolation, SLA's, management, security, provisioning, and routing isolation, SLA's, management, security, provisioning,
etc. MUST be preserved across adjacent ASÆs. The solutions MUST etc. MUST be preserved across adjacent ASs. The solutions MUST
describe the inter-SP network interface, encapsulation method(s), describe the inter-SP network interface, encapsulation method(s),
routing protocol(s), and all applicable parameters [VPN IW]. routing protocol(s), and all applicable parameters [VPN IW].
An essential pre-condition for an inter-AS VPN is an agreement An essential pre-condition for an inter-AS VPN is an agreement
between the AS's involved that spells out at least trust, economic, between the ASs involved that spells out at least trust, economic,
and management responsibilities. and management responsibilities.
The overall scalability of the VPN service MUST allow the L3VPN The overall scalability of the VPN service MUST allow the L3VPN
service to be offered across potentially hundreds of SPs, with the service to be offered across potentially hundreds of SPs, with the
overall scaling parameters per SP given in [PPVPN-GR]. overall scaling parameters per SP given in [PPVPN-GR].
6.10.1 Routing Protocols 6.10.1 Routing Protocols
If the link between AS's is not trusted, routing protocols running If the link between ASs is not trusted, routing protocols running
between those AS's MUST support some form of authentication. For between those ASs MUST support some form of authentication. For
example, the TCP option for carrying an MD5 digest may be used to example, the TCP option for carrying an MD5 digest may be used to
enhance security for BGP [RFC2385]. enhance security for BGP [RFC2385].
BGP MUST be supported as the standard inter-AS routing protocol to BGP MUST be supported as the standard inter-AS routing protocol to
control the path taken by L3VPN traffic. control the path taken by L3VPN traffic.
6.10.2 Management 6.10.2 Management
The general requirements for managing a single AS apply to a The general requirements for managing a single AS apply to a
concatenation of AS's. A minimum subset of such capabilities is the concatenation of ASs. A minimum subset of such capabilities is the
following: following:
- Diagnostic tools (e.g., ping, traceroute) - Diagnostic tools (e.g., ping, traceroute)
- Secured access to one AS management system by another - Secured access to one AS management system by another
Carugi, McDysan et al Informational - Expires December 2004 28 Carugi, McDysan et al Informational - Expires January 2005 28
Service requirements for Layer 3 PPVPNs July 2004
- Configuration request and status query tools - Configuration request and status query tools
- Fault notification and trouble tracking tools - Fault notification and trouble tracking tools
6.10.3 Bandwidth and QoS Brokering 6.10.3 Bandwidth and QoS Brokering
When a VPN spans multiple AS's, there is a need for a brokering When a VPN spans multiple ASs, there is a desire for a brokering
mechanism that requests certain SLA parameters, such as bandwidth mechanism that requests certain SLA parameters, such as bandwidth
and QoS, from the other domains and/or networks involved in and QoS, from the other domains and/or networks involved in
transferring traffic to various sites. The essential requirement is transferring traffic to various sites. Although bandwidth and QoS
that a solution MUST be able to determine whether a set of AS's can brokering across multiple ASs is not common in today's networks,
establish and guarantee uniform QoS in support of a L3VPN. these may be desirable in order to maintain SLAs in inter-AS VPNs.
This section describes requirements for features that would
facilitate these mechanisms. The objective is that a solution SHOULD
be able to determine whether a set of ASs can establish and
guarantee uniform QoS in support of a L3VPN.
The brokering mechanism can be a manual one, for example, where one The brokering mechanism can be a manual one, for example, where one
provider requests from another provider a specific set of QoS provider requests from another provider a specific set of bandwidth
parameters for traffic going to and from a specific set of sites. and QoS parameters for traffic going to and from a specific set of
The mechanism could also be an automated one where a device sites. The mechanism could also be an automated one where a device
dynamically requests and receives certain SLA/QoS parameters. For dynamically requests and receives certain bandwidth and SLA/QoS
instance, in the case of a L3 VPN over MPLS, a PE may negotiate the parameters. For instance, in the case of a L3 VPN over MPLS, a PE
label for different traffic classes to reach a PE residing in a may negotiate the label for different traffic classes to reach a PE
neighboring AS. Or, it might be a combination of both. For residing in a neighboring AS. Or, it might be a combination of both.
additional detailed requirements on the automated approach, see [TE- For additional detailed requirements on the automated approach, see
INTERAS]. [TE-INTERAS].
In the case of an automated function, which is desirable, the
functionality supported SHOULD dynamically request and reserve
certain QoS parameters such as bandwidth and priority, and then to
classify, mark and handle the packets as agreed in the negotiation.
Observe that as traffic might traverse multiple AS's, the brokering
method should also allow this.
It is not desirable to perform brokering on a per VPN basis since It is not desirable to perform brokering on a per VPN basis since
such an approach would not scale. A solution MUST provide some means such an approach would not scale. A solution MUST provide some means
of aggregating QoS and bandwidth brokering requests between AS's. of aggregating QoS and bandwidth brokering requests between ASs. One
One method could be for SP's to make an agreement specifying the method could be for SP's to make an agreement specifying the maximum
maximum amount of bandwidth for specific QoS parameters for all VPN amount of bandwidth for specific QoS parameters for all VPN
customers using the SP network. Alternatively, such aggregation customers using the SP network. Alternatively, such aggregation
might be on a per hierarchical tunnel basis between PE routers in might be on a per hierarchical tunnel basis between PE routers in
different AS's supporting a L3 VPN service. different ASs supporting a L3 VPN service [TE-INTERAS].
6.10.4 Security Considerations 6.10.4 Security Considerations
If a tunnel traverses multiple SP networks and it passes through an If a tunnel traverses multiple SP networks and it passes through an
unsecured SP, POP, NAP, or IX, then security mechanisms MUST be unsecured SP, POP, NAP, or IX, then security mechanisms MUST be
employed. These security mechanisms include encryption, employed. These security mechanisms include encryption,
authentication and resource protection as described in section 6.9 authentication and resource protection as described in section 6.9
and security management of section 7.5. For example, a provider and security management of section 7.5. For example, a provider
should consider use of both authentication and encryption for a should consider use of both authentication and encryption for a
tunnel used as part of a L3VPN that traverses another service tunnel used as part of a L3VPN that traverses another service
provider's network. provider's network.
6.11 L3VPN Wholesale 6.11 L3VPN Wholesale
The architecture MUST support the possibility of one service The architecture MUST support the possibility of one service
provider offering VPN service to another service provider. Another provider offering VPN service to another service provider. Another
example is when one service provider sells L3VPN service at example is when one service provider sells L3VPN service at
Carugi, McDysan et al Informational - Expires December 2004 29
wholesale to another service provider, who then resells that VPN wholesale to another service provider, who then resells that VPN
service to his or her customers. service to his or her customers.
The wholesalerÆs VPN MUST be transparent to the addressing and Carugi, McDysan et al Informational - Expires January 2005 29
Service requirements for Layer 3 PPVPNs July 2004
The wholesaler's VPN MUST be transparent to the addressing and
routing used by the reseller. routing used by the reseller.
Support for additional levels of hierarchy, for example three levels Support for additional levels of hierarchy, for example three levels
where a reseller can again resell the VPN service to yet another VPN where a reseller can again resell the VPN service to yet another VPN
provider, SHOULD be provided. provider, SHOULD be provided.
The CarrierÆs Carrier scenario is the name used in this document for The Carrier's Carrier scenario is the name used in this document for
this category of L3VPN wholesale (although some scenarios of Inter- this category of L3VPN wholesale (although some scenarios of Inter-
AS/Inter-Provider VPN could possibly fall in this L3VPN wholesale AS/Inter-Provider VPN could possibly fall in this L3VPN wholesale
category too). Various carrierÆs carrier scenarios should be category too). Various carrier's carrier scenarios should be
supported, such as: supported, such as:
- the customer Carriers do not operate L3VPN services for their - the customer Carriers do not operate L3VPN services for their
clients; clients;
- the customer Carriers operate L3VPN services for their clients, - the customer Carriers operate L3VPN services for their clients,
but these services are not linked with the L3VPN service offered but these services are not linked with the L3VPN service offered
by the CarriersÆ Carrier; by the Carrier's Carrier;
- the customer Carriers operate L3VPN services for their clients and - the customer Carriers operate L3VPN services for their clients and
these services are linked with the L3VPN service offered by the these services are linked with the L3VPN service offered by the
CarriersÆ Carrier ("Hierarchical VPNs" scenario) Carrier's Carrier ("Hierarchical VPNs" scenario)
6.12 Tunneling Requirements 6.12 Tunneling Requirements
Connectivity between CE sites or PE devices in the backbone SHOULD Connectivity between CE sites or PE devices in the backbone SHOULD
be able to use a range of tunneling technologies, such as L2TP, be able to use a range of tunneling technologies, such as L2TP,
IPSEC, GRE, IP-in-IP, MPLS, etc. IPSEC, GRE, IP-in-IP, MPLS, etc.
To set up tunnels between routers, every router MUST support static To set up tunnels between routers, every router MUST support static
configuration for tunneling and MAY support a tunnel setup protocol. configuration for tunneling and MAY support a tunnel setup protocol.
If employed, a tunnel establishment protocol SHOULD be capable of If employed, a tunnel establishment protocol SHOULD be capable of
conveying information, such as the following: conveying information, such as the following:
skipping to change at line 1512 skipping to change at line 1598
- Statistics, such as amount of time spent in the up and down - Statistics, such as amount of time spent in the up and down
state state
- Count of transitions between the up and down state - Count of transitions between the up and down state
- Events, such as transitions between the up and down states - Events, such as transitions between the up and down states
The tunneling technology used by the VPN Service Provider and its The tunneling technology used by the VPN Service Provider and its
associated mechanisms for tunnel establishment, multiplexing, and associated mechanisms for tunnel establishment, multiplexing, and
maintenance MUST meet the requirements on scaling, isolation, maintenance MUST meet the requirements on scaling, isolation,
security, QoS, manageability, etc. security, QoS, manageability, etc.
Carugi, McDysan et al Informational - Expires December 2004 30
6.13 Support for Access and Backbone Technologies 6.13 Support for Access and Backbone Technologies
This section describes requirements for aspects of access and This section describes requirements for aspects of access and
backbone network technologies from an SP point of view. backbone network technologies from an SP point of view.
Carugi, McDysan et al Informational - Expires January 2005 30
Service requirements for Layer 3 PPVPNs July 2004
Some SPs MAY desire that a single network infrastructure should Some SPs MAY desire that a single network infrastructure should
suffice for all services, public IP, VPNs, traffic engineering, and suffice for all services, public IP, VPNs, traffic engineering, and
differentiated services [L2 VPN]. differentiated services [L2 VPN].
6.13.1 Dedicated Access Networks 6.13.1 Dedicated Access Networks
Ideally, the L3VPN service SHOULD be independent of physical, link Ideally, the L3VPN service SHOULD be independent of physical, link
layer or even network technology of the access network. However, the layer or even network technology of the access network. However, the
characteristics of access networks MUST be accounted for when characteristics of access networks MUST be accounted for when
specifying the QoS aspects of SLAs for VPN service offerings. specifying the QoS aspects of SLAs for VPN service offerings.
skipping to change at line 1565 skipping to change at line 1654
6.13.3 Backbone Networks 6.13.3 Backbone Networks
Ideally, the backbone interconnecting SP PE and P devices SHOULD be Ideally, the backbone interconnecting SP PE and P devices SHOULD be
independent of physical and link layer technology. Nevertheless, the independent of physical and link layer technology. Nevertheless, the
characteristics of backbone technology MUST be taken into account characteristics of backbone technology MUST be taken into account
when specifying the QoS aspects of SLAs for VPN service offerings. when specifying the QoS aspects of SLAs for VPN service offerings.
6.14 Protection, Restoration 6.14 Protection, Restoration
When primary and secondary access connections are available, a L3VPN When primary and secondary access connections are available, a L3VPN
solution MUST provide restoration of access connectivity whenever solution MUST provide restoration of access connectivity whenever
Carugi, McDysan et al Informational - Expires December 2004 31
the primary access link from a CE site to a PE fails. This the primary access link from a CE site to a PE fails. This
restoration capability SHOULD be as automatic as possible, that is, restoration capability SHOULD be as automatic as possible, that is,
the traffic should be directed over the secondary link soon after the traffic should be directed over the secondary link soon after
failure of the primary access link is detected. Furthermore, failure of the primary access link is detected. Furthermore,
Carugi, McDysan et al Informational - Expires January 2005 31
Service requirements for Layer 3 PPVPNs July 2004
reversion to the primary link SHOULD be dynamic, if configured to do reversion to the primary link SHOULD be dynamic, if configured to do
so [VPN-NEEDS]. so [VPN-NEEDS].
As mentioned in Section 5.11.4 above, in the case of multi-homing, As mentioned in Section 5.11.4 above, in the case of multi-homing,
the load balancing capability MAY be used to achieve a degree of the load balancing capability MAY be used to achieve a degree of
redundancy in the network. In the case of failure of one or more redundancy in the network. In the case of failure of one or more
(but not all) of the multi-homed links, the load balancing (but not all) of the multi-homed links, the load balancing
parameters MAY be dynamically adjusted to rapidly redirect the parameters MAY be dynamically adjusted to rapidly redirect the
traffic from the failed link(s) to the surviving links. Once the traffic from the failed link(s) to the surviving links. Once the
failed link(s) is (are) restored, the original provisioned load failed link(s) is (are) restored, the original provisioned load
balancing ratio SHOULD be restored to its value prior to the balancing ratio SHOULD be restored to its value prior to the
failure. failure.
An SP SHOULD be able to deploy protection and restoration mechanisms An SP SHOULD be able to deploy protection and restoration mechanisms
within his or her backbone infrastructure to increase reliability within his or her backbone infrastructure to increase reliability
and fault tolerance of the VPN service offering. These techniques and fault tolerance of the VPN service offering. These techniques
SHOULD be scalable, and therefore should strive to not perform such SHOULD be scalable, and therefore should strive to not perform such
function in the backbone on a per-VPN basis. function in the backbone on a per-VPN basis.
Appropriate measurements and alarms that indicate how well network Appropriate measurements and alarms that indicate how well network
protection and restoration mechanisms are performing MUST be protection and restoration mechanisms are performing MUST be
supported. supported.
6.15 Interoperability 6.15 Interoperability
Service providers are interested in interoperability in at least the Service providers are interested in interoperability in at least the
skipping to change at line 1618 skipping to change at line 1710
MUST describe the inter-solution network interface, encapsulation MUST describe the inter-solution network interface, encapsulation
method(s), routing protocol(s), security, isolation, management, and method(s), routing protocol(s), security, isolation, management, and
all other applicable aspects of the overall VPN solution provided all other applicable aspects of the overall VPN solution provided
[VPN IW]. [VPN IW].
6.16 Migration Support 6.16 Migration Support
Service providers MUST have a graceful means to migrate a customer Service providers MUST have a graceful means to migrate a customer
with minimal service disruption on a site-by-site basis to a L3VPN with minimal service disruption on a site-by-site basis to a L3VPN
approach. approach.
Carugi, McDysan et al Informational - Expires December 2004 32
If L3VPN approaches can interwork or interconnect, then service If L3VPN approaches can interwork or interconnect, then service
providers MUST have a graceful means to migrate a customer with providers MUST have a graceful means to migrate a customer with
minimal service disruption on a site-by-site basis whenever changing minimal service disruption on a site-by-site basis whenever changing
interworking or interconnection. interworking or interconnection.
Carugi, McDysan et al Informational - Expires January 2005 32
Service requirements for Layer 3 PPVPNs July 2004
7 Service Provider Management Requirements 7 Service Provider Management Requirements
A service provider MUST have a means to view the topology, A service provider MUST have a means to view the topology,
operational state, order status, and other parameters associated operational state, order status, and other parameters associated
with each customer's VPN. Furthermore, an SP MUST have a means to with each customer's VPN. Furthermore, an SP MUST have a means to
view the underlying logical and physical topology, operational view the underlying logical and physical topology, operational
state, provisioning status, and other parameters associated with the state, provisioning status, and other parameters associated with the
equipment providing the VPN service(s) to its customers. equipment providing the VPN service(s) to its customers.
Currently, proprietary methods are often used to manage VPNs. The Currently, proprietary methods are often used to manage VPNs. The
additional expense associated with operators having to use multiple additional expense associated with operators having to use multiple
skipping to change at line 1670 skipping to change at line 1765
It is desirable to detect faults caused by configuration errors, It is desirable to detect faults caused by configuration errors,
because these may cause VPN service to fail, or not meet other because these may cause VPN service to fail, or not meet other
requirements (e.g., traffic and routing isolation). This is a requirements (e.g., traffic and routing isolation). This is a
likely case of compromised security [VPNSEC]. Detection of such likely case of compromised security [VPNSEC]. Detection of such
errors is inherently difficult because the problem involves more errors is inherently difficult because the problem involves more
than one node and may reach across a global perspective. One than one node and may reach across a global perspective. One
approach could be a protocol that systematically checks that all approach could be a protocol that systematically checks that all
constraints and consistency checks hold among tunnel configuration constraints and consistency checks hold among tunnel configuration
parameters at the various end points. parameters at the various end points.
Carugi, McDysan et al Informational - Expires December 2004 33 A capability to verify L3 reachability within a VPN MUST be provided
A capability to verify L3 reachability within a VPN MUST beprovided
for diagnostic purposes. for diagnostic purposes.
A capability to verify the parameter configuration of a device A capability to verify the parameter configuration of a device
supporting a L3VPN MUST be provided for diagnostic purposes. supporting a L3VPN MUST be provided for diagnostic purposes.
Carugi, McDysan et al Informational - Expires January 2005 33
Service requirements for Layer 3 PPVPNs July 2004
7.2 Configuration Management 7.2 Configuration Management
Overall, the NMS must support configuration necessary to realize Overall, the NMS must support configuration necessary to realize
desired L3 reachability of a L3VPN. Toward this end, an NMS MUST desired L3 reachability of a L3VPN. Toward this end, an NMS MUST
provide configuration management to provision at least the following provide configuration management to provision at least the following
L3VPN components: PE,CE, hierarchical tunnels, access connections, L3VPN components: PE,CE, hierarchical tunnels, access connections,
routing, and QoS, as detailed in this section. If shared access to routing, and QoS, as detailed in this section. If shared access to
the Internet is provided, then this option MUST also be the Internet is provided, then this option MUST also be
configurable. configurable.
Since VPN configuration and topology are highly dependent upon a Since VPN configuration and topology are highly dependent upon a
skipping to change at line 1723 skipping to change at line 1821
BGP policy, such as for expressing a preference about an exit router BGP policy, such as for expressing a preference about an exit router
for a particular destination. for a particular destination.
The set of service templates SHOULD be comprehensive in that they The set of service templates SHOULD be comprehensive in that they
can capture all service orders in some meaningful sense. can capture all service orders in some meaningful sense.
The provider SHOULD provide means for translating instantiated The provider SHOULD provide means for translating instantiated
service templates into device configurations so that associated service templates into device configurations so that associated
services can be provisioned. services can be provisioned.
Carugi, McDysan et al Informational - Expires December 2004 34
Finally, the approach SHOULD provide means for checking if a service Finally, the approach SHOULD provide means for checking if a service
order is correctly provisioned. This would represent one method of order is correctly provisioned. This would represent one method of
diagnosing configuration errors. Configuration errors can arise due diagnosing configuration errors. Configuration errors can arise due
to a variety of reasons: manual configuration, intruder to a variety of reasons: manual configuration, intruder attacks, and
attacks,conflicting service requirements. conflicting service requirements.
Carugi, McDysan et al Informational - Expires January 2005 34
Service requirements for Layer 3 PPVPNs July 2004
7.2.1 Configuration Management for PE-Based VPNs 7.2.1 Configuration Management for PE-Based VPNs
Requirements for configuration management unique to a PE-based VPN Requirements for configuration management unique to a PE-based VPN
are as follows. are as follows.
o The NMS MUST support configuration of at least the following o The NMS MUST support configuration of at least the following
aspects of a L3 PE routers: intranet and extranet membership, CE aspects of a L3 PE routers: intranet and extranet membership, CE
routing protocol for each access connection, routing metrics, routing protocol for each access connection, routing metrics,
tunnels, etc. tunnels, etc.
skipping to change at line 1773 skipping to change at line 1874
are as follows. are as follows.
o Tunnels MUST be configured between CE devices. This requires o Tunnels MUST be configured between CE devices. This requires
coordination of identifiers of tunnels, VPNs, and any associated coordination of identifiers of tunnels, VPNs, and any associated
service information, for example, a QoS/SLA service. service information, for example, a QoS/SLA service.
o Routing protocols running between PE routers and CE devices MUST o Routing protocols running between PE routers and CE devices MUST
be configured. For multicast service, multicast routing protocols be configured. For multicast service, multicast routing protocols
MUST also be configurable. MUST also be configurable.
Carugi, McDysan et al Informational - Expires December 2004 35
7.2.3 Provisioning Routing 7.2.3 Provisioning Routing
A means for a service provider to provision parameters for the IGP A means for a service provider to provision parameters for the IGP
for a L3VPN MUST be provided. This includes link level metrics, for a L3VPN MUST be provided. This includes link level metrics,
capacity, QoS capability, and restoration parameters. capacity, QoS capability, and restoration parameters.
7.2.4 Provisioning Network Access 7.2.4 Provisioning Network Access
A service provider MUST have the means to provision network access A service provider MUST have the means to provision network access
between SP-managed PE and CE, as well as the case where the customer between SP-managed PE and CE, as well as the case where the customer
manages the CE. manages the CE.
Carugi, McDysan et al Informational - Expires January 2005 35
Service requirements for Layer 3 PPVPNs July 2004
7.2.5 Provisioning Security Services 7.2.5 Provisioning Security Services
When a security service is requested, an SP MUST have the means to When a security service is requested, an SP MUST have the means to
provision the entities and associated parameters involved with the provision the entities and associated parameters involved with the
service. For example, for IPsec service, tunnels, options, keys, and service. For example, for IPsec service, tunnels, options, keys, and
other parameters must be provisioned at either the CE and/or PE. In other parameters must be provisioned at either the CE and/or PE. In
the case of an intrusion detection service, the filtering and the case of an intrusion detection service, the filtering and
detection rules must be provisioned on a VPN basis. detection rules must be provisioned on a VPN basis.
7.2.6 Provisioning VPN Resource Parameters 7.2.6 Provisioning VPN Resource Parameters
A service provider MUST have a means to dynamically provision A service provider MUST have a means to dynamically provision
resources associated with VPN services. For example, in a PE-based resources associated with VPN services. For example, in a PE-based
service, the number and size of virtual switching and forwarding service, the number and size of virtual switching and forwarding
table instances must be provisionable. table instances must be provisionable.
Dynamic VPN resource assignment is crucial to cope with the frequent Dynamic VPN resource assignment is crucial to cope with the frequent
changes requests from customerÆs (e.g., sites joining or leaving a changes requests from customer's (e.g., sites joining or leaving a
VPN), as well as to achieve scalability. The PEs SHOULD be able to VPN), as well as to achieve scalability. The PEs SHOULD be able to
dynamically assign the VPN resources. This capability is especially dynamically assign the VPN resources. This capability is especially
important for dial and wireless VPN services. important for dial and wireless VPN services.
If an SP supports a "Dynamic Bandwidth management" service, then the If an SP supports a "Dynamic Bandwidth management" service, then the
provisioning system MUST be able to make requested changes within provisioning system MUST be able to make requested changes within
the ranges and bounds specified in the Service Level Agreement the ranges and bounds specified in the Service Level Agreement
(SLA). Examples of SLA parameters are response time and probability (SLA). Examples of SLA parameters are response time and probability
of being able to service such a request. of being able to service such a request.
skipping to change at line 1826 skipping to change at line 1930
scope of this document to define if and how these different services scope of this document to define if and how these different services
interact with the VPN in order to solve issues such as addressing, interact with the VPN in order to solve issues such as addressing,
integrity and security. However, the VPN service MUST be able to integrity and security. However, the VPN service MUST be able to
provide access to these various types of value-added services. provide access to these various types of value-added services.
A VPN service SHOULD allow the SP to supply the customer with A VPN service SHOULD allow the SP to supply the customer with
different kinds of standard IP services, like DNS, NTP and RADIUS different kinds of standard IP services, like DNS, NTP and RADIUS
needed for ordinary network operation and management. The provider needed for ordinary network operation and management. The provider
SHOULD be able to provide IP services to multiple VPN customers. SHOULD be able to provide IP services to multiple VPN customers.
Carugi, McDysan et al Informational - Expires December 2004 36
A firewall function MAY be required to restrict access to the L3VPN A firewall function MAY be required to restrict access to the L3VPN
from the Internet [Y.1311]. from the Internet [Y.1311].
A managed firewall service MUST be carrier grade. For redundancy and A managed firewall service MUST be carrier grade. For redundancy and
failure recovery, a means for firewall fail-over should be provided. failure recovery, a means for firewall fail-over should be provided.
Managed firewall services that may be provided include dropping Managed firewall services that may be provided include dropping
specified protocol types, intrusion protection, traffic-rate specified protocol types, intrusion protection, traffic-rate
limiting against malicious attacks, etc. limiting against malicious attacks, etc.
Carugi, McDysan et al Informational - Expires January 2005 36
Service requirements for Layer 3 PPVPNs July 2004
Managed firewalls MUST be supported on a per-VPN basis, although Managed firewalls MUST be supported on a per-VPN basis, although
multiple VPNs may be supported by the same physical device (e.g., in multiple VPNs may be supported by the same physical device (e.g., in
PE-based solution). Managed firewalls SHOULD be provided at the PE-based solution). Managed firewalls SHOULD be provided at the
major access point(s) for the L3VPN. Managed firewall services may major access point(s) for the L3VPN. Managed firewall services may
be embedded in CE or PE device, or implemented in standalone be embedded in CE or PE device, or implemented in standalone
devices. devices.
The NMS SHOULD allow a customer to outsource the management of an IP The NMS SHOULD allow a customer to outsource the management of an IP
networking service to the SP providing the VPN or to a third party. networking service to the SP providing the VPN or to a third party.
skipping to change at line 1876 skipping to change at line 1983
A L3VPN solution MUST describe how the following accounting A L3VPN solution MUST describe how the following accounting
functions can be provided: functions can be provided:
- measurements of resource utilization, - measurements of resource utilization,
- collection of accounting information, - collection of accounting information,
- storage and administration of measurements. - storage and administration of measurements.
Some providers may require near-real time reporting of measurement Some providers may require near-real time reporting of measurement
information, and may offer this as part of a customer network information, and may offer this as part of a customer network
management service. management service.
Carugi, McDysan et al Informational - Expires December 2004 37
If an SP supports a "Dynamic Bandwidth management" service, then the If an SP supports a "Dynamic Bandwidth management" service, then the
dates, times, amounts and interval required to perform requested dates, times, amounts and interval required to perform requested
bandwidth allocation change(s) MUST be traceable for monitoring and bandwidth allocation change(s) MUST be traceable for monitoring and
accounting purposes. accounting purposes.
Solutions should state compliance to accounting requirements, as Solutions should state compliance to accounting requirements, as
described in section 1.7 of RFC 2975. described in section 1.7 of RFC 2975.
Carugi, McDysan et al Informational - Expires January 2005 37
Service requirements for Layer 3 PPVPNs July 2004
7.4 Performance Management 7.4 Performance Management
Performance management MUST support functions involved with Performance management MUST support functions involved with
monitoring and collecting performance data regarding devices, monitoring and collecting performance data regarding devices,
facilities, and services, as well as determination of conformance to facilities, and services, as well as determination of conformance to
Service Level Specifications (SLS), such as QoS and availability Service Level Specifications (SLS), such as QoS and availability
measurements. measurements.
Performance management SHOULD also support analysis of important Performance management SHOULD also support analysis of important
aspects of a L3VPN , such as bandwidth utilization, response time, aspects of a L3VPN , such as bandwidth utilization, response time,
availability, QoS statistics, and trends based on collected data. availability, QoS statistics, and trends based on collected data.
skipping to change at line 1927 skipping to change at line 2037
techniques, and methods as defined by the IETF IP Performance techniques, and methods as defined by the IETF IP Performance
Metrics (IPPM) working group for delay, loss, and delay variation. Metrics (IPPM) working group for delay, loss, and delay variation.
The NMS SHOULD support allocation and measurement of end-to-end QoS The NMS SHOULD support allocation and measurement of end-to-end QoS
requirements to QoS parameters for one or more VPN network(s). requirements to QoS parameters for one or more VPN network(s).
Devices supporting L3VPN SLAs SHOULD have real-time performance Devices supporting L3VPN SLAs SHOULD have real-time performance
measurements that have indicators and threshold crossing alerts. measurements that have indicators and threshold crossing alerts.
Such thresholds should be configurable. Such thresholds should be configurable.
Carugi, McDysan et al Informational - Expires December 2004 38
7.5 Security Management 7.5 Security Management
The security management function of the NMS MUST include management The security management function of the NMS MUST include management
features to guarantee the security of devices, access connections, features to guarantee the security of devices, access connections,
and protocols within the L3VPN network(s), as well as the security and protocols within the L3VPN network(s), as well as the security
of customer data and control as described in section 6.9. of customer data and control as described in section 6.9.
7.5.1 Resource Access Control 7.5.1 Resource Access Control
Resource access control determines the privileges that a user has to Resource access control determines the privileges that a user has to
access particular applications and VPN network resources. Without access particular applications and VPN network resources. Without
such control, only the security of the data and control traffic is such control, only the security of the data and control traffic is
Carugi, McDysan et al Informational - Expires January 2005 38
Service requirements for Layer 3 PPVPNs July 2004
protected, leaving the devices providing the L3VPN network protected, leaving the devices providing the L3VPN network
unprotected. Access control capabilities protect these devices to unprotected. Access control capabilities protect these devices to
ensure that users have access to only the resources and applications ensure that users have access to only the resources and applications
to which they are authorized to use. to which they are authorized to use.
In particular, access to the routing and switching resources managed In particular, access to the routing and switching resources managed
by the SP MUST be tightly controlled to prevent and/or effectively by the SP MUST be tightly controlled to prevent and/or effectively
mitigate a malicious attack. More detailed requirements in this area mitigate a malicious attack. More detailed requirements in this area
are described in [VPNSEC]. are described in [VPNSEC].
skipping to change at line 1980 skipping to change at line 2094
middle attack, because the endpoints never verify each other. A middle attack, because the endpoints never verify each other. A
weakly-authenticated VPN AP may be subject to such an attack. weakly-authenticated VPN AP may be subject to such an attack.
Strongly-authenticated VPN APs are not subject to such attacks, Strongly-authenticated VPN APs are not subject to such attacks,
because the man-in-the-middle cannot be authenticated as the real because the man-in-the-middle cannot be authenticated as the real
AP, due to the strong authentication algorithms. AP, due to the strong authentication algorithms.
7.6 Basis and Presentation Techniques of Management Information 7.6 Basis and Presentation Techniques of Management Information
Each L3VPN solution approach MUST specify the management information Each L3VPN solution approach MUST specify the management information
bases (MIB) modules for the network elements involved in L3VPN bases (MIB) modules for the network elements involved in L3VPN
services. This is an essential requirement in network provisioning. services. This is an essential requirement in network provisioning.
Carugi, McDysan et al Informational - Expires December 2004 39
The approach SHOULD identify any information not contained in a The approach SHOULD identify any information not contained in a
standard MIB related to FCAPS that is necessary to meet a generic standard MIB related to FCAPS that is necessary to meet a generic
requirement. requirement.
An IP VPN (Policy)Information model, when available, SHOULD reuse An IP VPN (Policy)Information model, when available, SHOULD reuse
the policy information models being developed in parallel for the policy information models being developed in parallel for
specific IP network capabilities [IM-REQ]. This includes the QoS specific IP network capabilities [IM-REQ]. This includes the QoS
Policy Information Model_[QPIM] and the IPSEC Configuration Policy Policy Information Model_[QPIM] and the IPSEC Configuration Policy
Model_ [IPSECIM]. The IP VPN Information model SHOULD provide the Model_ [IPSECIM]. The IP VPN Information model SHOULD provide the
OSS with adequate "hooks" to correlate service level specifications OSS with adequate "hooks" to correlate service level specifications
Carugi, McDysan et al Informational - Expires January 2005 39
Service requirements for Layer 3 PPVPNs July 2004
with traffic data collected from network elements. The use of with traffic data collected from network elements. The use of
policies includes rules that control corrective actions taken by OSS policies includes rules that control corrective actions taken by OSS
components responsible for monitoring the network and ensuring that components responsible for monitoring the network and ensuring that
it meets service requirements. it meets service requirements.
Additional requirements on VPN information models are given in Additional requirements on VPN information models are given in
reference [IM-PPVPN]. In particular, an information model MUST allow reference [IM-PPVPN]. In particular, an information model MUST allow
an SP to change VPN network dimensions with minimal influence on an SP to change VPN network dimensions with minimal influence on
provisioning issues. The adopted model SHOULD be applicable to both provisioning issues. The adopted model SHOULD be applicable to both
small/medium size and large-scale L3VPN scenarios. small/medium size and large-scale L3VPN scenarios.
Some service providers MAY require systems that visually, audibly, Some service providers MAY require systems that visually, audibly,
or logically present FCAPS information to internal operators and/or or logically present FCAPS information to internal operators and/or
customers. customers.
8 Security Considerations 8 Security Considerations
Security considerations occur at several levels and dimensions Security considerations occur at several levels and dimensions
within L3 VPNs, as detailed within this document. This section within L3 VPNs, as detailed within this document. This section
provides a summary with references to supporting detailed provides a summary with references to supporting detailed
information. information.
The requirements in this document separate the notion of traditional The requirements in this document separate the notion of traditional
security requirements, such as integrity, confidentiality, and security requirements, such as integrity, confidentiality, and
authentication (as detailed in section Error! Reference source not authentication from that of isolating (or separating) the exchange
found.) from that of isolating (or separating) the exchange of VPN of VPN data and control traffic between specific sets of sites (as
data and control traffic between specific sets of sites (as defined defined in sections 3.3 and 4.1). Further detail on security
in sections 3.3 and 4.1). Further detail on security requirements is requirements is given from the customer and service provider
given from the customer and service provider perspectives in perspectives in sections 5.9 and 6.9, respectively. In an analogous
sections Error! Reference source not found. and 5.9, respectively. manner, further detail on data and control traffic isolation
In an analogous manner, further detail on data and control traffic requirements are given from the customer and service provider
isolation requirements are given from the customer and service perspectives in sections 5.1 and 6.8, respectively. Additionally,
provider perspectives in sections 4.1 and 5.8, respectively. references to a document [VPNSEC] specifically addressing security
Additionally, references to a document [VPNSEC] specifically requirements are made where appropriate.
addressing security requirements are made where appropriate.
Furthermore, requirements regarding management of security from a Furthermore, requirements regarding management of security from a
service provider perspective are described in section 7.5. service provider perspective are described in section 7.5.
9 Acknowledgements 9 Acknowledgements
The authors of this document would like to acknowledge the The authors of this document would like to acknowledge the
contributions from the people who launched the work on VPN contributions from the people who launched the work on VPN
requirements inside ITU-T SG13, the authors of the original IP VPN requirements inside ITU-T SG13, the authors of the original IP VPN
Carugi, McDysan et al Informational - Expires December 2004 40
requirements and framework document [RFC 2764], as well as Tom requirements and framework document [RFC 2764], as well as Tom
Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau,
Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le
Garrec. The authors are also grateful to the helpful suggestions and Garrec. The authors are also grateful to the helpful suggestions and
direction provided by the technical advisors, Alex Zinin, Scott direction provided by the technical advisors, Alex Zinin, Scott
Bradner, Bert Wijnen and Rob Coltun. Finally, the authors also wish Bradner, Bert Wijnen and Rob Coltun. Finally, the authors also wish
to acknowledge the insights and requirements gleaned from the many to acknowledge the insights and requirements gleaned from the many
documents listed in the references section. Citations to these documents listed in the references section. Citations to these
documents were made only where the authors believed that additional documents were made only where the authors believed that additional
insight to the requirement could be obtained by reading the source insight to the requirement could be obtained by reading the source
document. document.
Carugi, McDysan et al Informational - Expires January 2005 40
Service requirements for Layer 3 PPVPNs July 2004
10 References 10 References
10.1 Normative References 10.1 Normative References
[PPVPN-GR] Nagarajan, A., "Generic Requirements for Provider [RFC 3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned VPN," Work in Progress. Provisioned VPN," Work in Progress.
[RFC 3377] Hodges, J., Morgan, R. ôLightweight Directory Access [RFC 3377] Hodges, J., Morgan, R. "Lightweight Directory Access
Protocol (v3): Technical Specification,ö RFC 3377, Protocol (v3): Technical Specification," RFC 3377,
September 2002 September 2002
[RFC 1918] Rekhter, Y., et al., "Address Allocation for Private [RFC 1918] Rekhter, Y., et al., "Address Allocation for Private
Internets," RFC 1918, February 1996. Internets," RFC 1918, February 1996.
[RFC 2026] Bradner, S., "The Internet Standards Process -- [RFC 2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996. Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC 2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., [RFC 2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
Jamin, S. "Resource ReSerVation Protocol (RSVP) -- Jamin, S. "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification," September 1997. Version 1 Functional Specification," September 1997.
skipping to change at line 2082 skipping to change at line 2200
Protocol (v3)," RFC 2251, December 1997. Protocol (v3)," RFC 2251, December 1997.
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., Weiss, W. "An Architecture for Differentiated Z., Weiss, W. "An Architecture for Differentiated
Services", RFC 2475, Dec. 1998. Services", RFC 2475, Dec. 1998.
[RFC 2597] Baker, F., Heinanen, J., Weiss, W., Wroclawski, J. [RFC 2597] Baker, F., Heinanen, J., Weiss, W., Wroclawski, J.
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC 2661] Townsley, W. et al., "Layer Two Tunneling Protocol [RFC 2661] Townsley, W. et al., "Layer Two Tunneling Protocol
"L2TP"," RFC 2661, August 1999. "L2TP"," RFC 2661, August 1999.
[RFC 2685] Fox B., et al, "Virtual Private Networks Identifier", [RFC 2685] Fox B., et al, "Virtual Private Networks Identifier",
RFC 2685, September 1999. RFC 2685, September 1999.
[RFC 2983] Black, D. ôDifferentiated Services and Tunnelsö, [RFC 2983] Black, D. "Differentiated Services and Tunnels,"
RFC2983, October 2000 RFC2983, October 2000
[RFC 3031] Rosen, E., Viswanathan, A., Callon, R. "Multiprotocol [RFC 3031] Rosen, E., Viswanathan, A., Callon, R. "Multiprotocol
Label Switching Architecture," January 2001. Label Switching Architecture," January 2001.
Carugi, McDysan et al Informational - Expires December 2004 41
[RFC 3246] Davie, B., et al., "An Expedited Forwarding PHB", RFC [RFC 3246] Davie, B., et al., "An Expedited Forwarding PHB", RFC
3246, March 2002. 3246, March 2002.
[RFC 3270] Le Faucheur, F., et al., ôMulti-Protocol Label [RFC 3270] Le Faucheur, F., et al., "Multi-Protocol Label
Switching (MPLS) Support of Differentiated Services,ö Switching (MPLS) Support of Differentiated Services,"
RFC 3270, May 2002 RFC 3270, May 2002
10.2 Non-normative References 10.2 Non-normative References
[2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work
in progress. in progress.
[2917bis] Muthukrishnan, K., et al., ô A Core MPLS IP VPN [2917bis] Muthukrishnan, K., et al., "A Core MPLS IP VPN
Architectureö, work in progress Architecture," work in progress
Carugi, McDysan et al Informational - Expires January 2005 41
Service requirements for Layer 3 PPVPNs July 2004
[DOCSIS 1.1] Data Over Cable Service Interface Specification [DOCSIS 1.1] Data Over Cable Service Interface Specification
(DOCSIS), Cable Labs, (DOCSIS), Cable Labs,
http://www.cablemodem.com/specifications.html http://www.cablemodem.com/specifications.html
[FRF.13] Frame Relay Forum, "Service Level Definitions [FRF.13] Frame Relay Forum, "Service Level Definitions
Implementation Agreement," August, 1998. Implementation Agreement," August, 1998.
[IM-PPVPN] Lago, P., et al., "An Information Model for Provider [IM-PPVPN] Lago, P., et al., "An Information Model for Provider
Provisioned Virtual Private Networks," work in Provisioned Virtual Private Networks," work in
progress. progress.
[IM-REQ] Iyer, M., et al., "Requirements for an IP VPN Policy [IM-REQ] Iyer, M., et al., "Requirements for an IP VPN Policy
Information Model," work in progress Information Model," work in progress
[IPSECIM] Jason, J.,_"IPsec Configuration Policy Model," work [IPSECIM] Jason, J., "IPsec Configuration Policy Model," work
in progress. in progress.
[CE-PPVPN] De Clercq, J., Paridaens, O., Krywaniuk, A., Wang, [CE-PPVPN] De Clercq, J., Paridaens, O., Krywaniuk, A., Wang,
C., ôAn Architecture for Provider Provisioned CE- C., "An Architecture for Provider Provisioned CE-
based Virtual Private Networks using IPsec,ö work in based Virtual Private Networks using IPsec," work in
progress progress
[IPSEC-PPVPN] Gleeson, B., "Uses of IPsec with Provider [IPSEC-PPVPN] Gleeson, B., "Uses of IPsec with Provider
Provisioned VPNs," work in progress. Provisioned VPNs," work in progress.
[L2 MPLS] Martini, L., et al., ôTransport of Layer 2 Frames [L2 MPLS] Martini, L., et al., "Transport of Layer 2 Frames
Over MPLS,ö work in progress. Over MPLS," work in progress.
[L2 VPN] Rosen, E., et al., "An Architecture for L2VPNs," [L2 VPN] Rosen, E., et al., "An Architecture for L2VPNs,"
work in progress. work in progress.
[L2 VPN] Kompella, K., Bonica, R., "Whither Layer 2 VPNs?," [L2 VPN] Kompella, K., Bonica, R., "Whither Layer 2 VPNs?,"
work in progress. work in progress.
[MPLS SEC] Behringer, M., "Analysis of the Security of the MPLS [MPLS SEC] Behringer, M., "Analysis of the Security of the MPLS
Architecture," work in progress Architecture," work in progress
[PPVPN-TERM] Andersson, L., Madsen, T., ôPPVPN Terminology,ö work [PPVPN-TERM] Andersson, L., Madsen, T., "PPVPN Terminology," work
in progress in progress
[L3VPN-SEC] Fang, L., et al., ôSecurity Framework for Provider [L3VPN-SEC] Fang, L., et al., "Security Framework for Provider
Provisioned Virtual Private Networks,ö work in Provisioned Virtual Private Networks," work in
progress. progress.
[NBVPN-FR] Suzuki, M. and Sumimoto, J. (editors), "A framework [NBVPN-FR] Suzuki, M. and Sumimoto, J. (editors), "A framework
for Network-based VPNs", work in progress for Network-based VPNs", work in progress
[L3VPN-FR] Callon, R., Suzuki, M., et al. "A Framework for [L3VPN-FR] Callon, R., Suzuki, M., et al. "A Framework for
Layer 3 Provider Provisioned Virtual Private Layer 3 Provider Provisioned Virtual Private
Networks ",work in progress Networks ",work in progress
[PPVPN-VR] Knight, P., Ould-Brahim, H., Gleeson, B., "Network [PPVPN-VR] Knight, P., Ould-Brahim, H., Gleeson, B., "Network
based IP VPN Architecture using Virtual based IP VPN Architecture using Virtual
Routers", work in progress Routers," work in progress
[QPIM] Snir, Ramberg, Strassner, Cohen and Moore,_"Policy [QPIM] Snir, Ramberg, Strassner, Cohen and Moore, "Policy
QoS Information Model" work in progress. QoS Information Model," work in progress.
[RFC 2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs," RFC 2547,
Carugi, McDysan et al Informational - Expires December 2004 42
[RFC 2547] Rosen, E., Rekhter, Y., ôBGP/MPLS VPNs,ö RFC 2547,
March 1999. March 1999.
[RFC 2764] Gleeson, B., et al., "A Framework for IP based Virtual [RFC 2764] Gleeson, B., et al., "A Framework for IP based Virtual
Private Networks", RFC 2764, February 2000. Private Networks", RFC 2764, February 2000.
[RFC 2975] Aboba, B., et al., "Introduction to Accounting [RFC 2975] Aboba, B., et al., "Introduction to Accounting
Management," October 2000. Management," October 2000.
[RFC 3198] Westerinen, A., et al., "Terminology for Policy-Based [RFC 3198] Westerinen, A., et al., "Terminology for Policy-Based
Management," November, 2001. Management," November, 2001.
[TE-INTERAS] Le Roux, JL., Boyle, J., et al., ôRequirements for [TE-INTERAS] Zhang, R., Vasssuer, J.P., "MPLS Inter-AS Traffic
Inter-area MPLS Traffic Engineering,ö work in Engineering requirements," work in progress.
progress.
[VPN DISC] Squire, M. et al., "VPN Discovery Discussions and [VPN DISC] Squire, M. et al., "VPN Discovery Discussions and
Carugi, McDysan et al Informational - Expires January 2005 42
Service requirements for Layer 3 PPVPNs July 2004
Options," work in progress. Options," work in progress.
[VPN IW] Kurakami, H., et al., "Provider-Provisioned VPNs [VPN IW] Kurakami, H., et al., "Provider-Provisioned VPNs
Interworking," work in progress. Interworking," work in progress.
[VPN SEC] De Clercq, J., et al., "Considerations about [VPN SEC] De Clercq, J., et al., "Considerations about
possible security extensions to BGP/MPLS VPN," work possible security extensions to BGP/MPLS VPN," work
in progress. in progress.
[VPN TUNNEL] Worster, T., et al., "A PPVPN Layer Separation: VPN [VPN TUNNEL] Worster, T., et al., "A PPVPN Layer Separation: VPN
Tunnels and Core Connectivity," work in progress Tunnels and Core Connectivity," work in progress
[VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V., [VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V.,
"Criteria for Evaluating VPN Implementation "Criteria for Evaluating VPN Implementation
skipping to change at line 2171 skipping to change at line 2291
possible security extensions to BGP/MPLS VPN," work possible security extensions to BGP/MPLS VPN," work
in progress. in progress.
[VPN TUNNEL] Worster, T., et al., "A PPVPN Layer Separation: VPN [VPN TUNNEL] Worster, T., et al., "A PPVPN Layer Separation: VPN
Tunnels and Core Connectivity," work in progress Tunnels and Core Connectivity," work in progress
[VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V., [VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V.,
"Criteria for Evaluating VPN Implementation "Criteria for Evaluating VPN Implementation
Mechanisms", work in progress Mechanisms", work in progress
[VPN-NEEDS] Jacquenet, C., "Functional needs for the deployment [VPN-NEEDS] Jacquenet, C., "Functional needs for the deployment
of an IP VPN service offering : a service provider of an IP VPN service offering : a service provider
perspective ", work in progress perspective ", 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 Recommendation, January 2001. Services", Y.1241 ITU-T Recommendation, January
2001.
[Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS [Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS
architecture",Y.1311.1 ITU-T Recommendation, July2001. architecture",Y.1311.1 ITU-T Recommendation,
[Y.1311] Knightson, K. (editor), " Network based VPNs - July2001.
Generic Architectureand Service Requirements ", Y.1311 [Y.1311] Knightson, K. (editor), "Network based VPNs -
ITU-T Recommendation, March 2002. Generic Architecture and Service Requirements,"
Y.1311 ITU-T Recommendation, March 2002.
11 Authors' address 11 Authors' address
Marco Carugi (Co-editor) Marco Carugi (Co-editor)
Nortel Networks Nortel Networks
Parc d'activit‰s de Magny-Les Jeunes Bois CHATEAUFORT Parc d'activit‰s de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - FRANCE 78928 YVELINES Cedex 9 - FRANCE
EMail: marco.carugi@nortelnetworks.com EMail: marco.carugi@nortelnetworks.com
Dave McDysan (Co-editor) Dave McDysan (Co-editor)
MCI MCI
22001 Loudoun County Parkway 22001 Loudoun County Parkway
Ashburn, VA 20147, USA Ashburn, VA 20147, USA
EMail: dave.mcdysan@mci.com EMail: dave.mcdysan@mci.com
Luyuan Fang Luyuan Fang
AT&T AT&T
Carugi, McDysan et al Informational - Expires December 2004 43
200 Laurel Ave - Room C2-3B35 200 Laurel Ave - Room C2-3B35
Middletown, NJ 07748 USA Middletown, NJ 07748 USA
EMail: Luyuanfang@att.com EMail: Luyuanfang@att.com
Ananth Nagarajan Ananth Nagarajan
Juniper Networks Juniper Networks
EMail: ananth@juniper.net EMail: ananth@juniper.net
Junichi Sumimoto Junichi Sumimoto
NTT Communications Corporation NTT Communications Corporation
3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan 3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan
EMail: j.sumimoto@ntt.com EMail: j.sumimoto@ntt.com
Carugi, McDysan et al Informational - Expires January 2005 43
Service requirements for Layer 3 PPVPNs July 2004
Rick Wilder Rick Wilder
Alcatel Alcatel
EMail: rick.wilder@alcatel.com EMail: rick.wilder@alcatel.com
Full copyright statement Full copyright statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
skipping to change at line 2243 skipping to change at line 2366
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Carugi, McDysan et al Informational - Expires December 2004 44 Carugi, McDysan et al Informational - Expires January 2005 44
 End of changes. 118 change blocks. 
169 lines changed or deleted 292 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/