7. Service Provider Management Requirements
A service provider MUST have a means to view the topology,
operational state, order status, and other parameters associated with
each customer's VPN. Furthermore, an SP MUST have a means to view
the underlying logical and physical topology, operational state,
provisioning status, and other parameters associated with the
equipment providing the VPN service(s) to its customers.
Currently, proprietary methods are often used to manage VPNs. The
additional expense associated with operators using multiple
proprietary management methods (e.g., command line interface (CLI)
languages) to access such systems is undesirable. Therefore, devices
SHOULD provide standards-based interfaces wherever feasible.
The remainder of this section presents detailed SP management
requirements for a Network Management System (NMS) in the traditional
fault, configuration, accounting, performance, and security (FCAPS)
management categories. Much of this text was adapted from ITU-T
7.1. Fault Management
Support for fault management includes:
- indication of customers impacted by failure,
- fault detection (incidents reports, alarms and failure
- fault localization (analysis of alarms reports and diagnostics),
- incident recording or logs (creation and follow-through of trouble
- corrective actions (traffic, routing, and resource allocation).
As PE-based VPNs rely on a common network infrastructure, the NMS
MUST provide a means to inform the provider of the VPN customers
impacted by a failure in the infrastructure. The NMS SHOULD provide
pointers to the related customer configuration information to aid in
fault isolation and determining corrective action.
Detecting faults caused by configuration errors is desirable, because
these may cause VPN service failure or may disrupt other requirements
(e.g., traffic and routing isolation). This is a likely case of
compromised security [VPNSEC]. Detection of such errors is
inherently difficult because the problem involves more than one node
and may reach across a global perspective. One approach could be a
protocol that systematically checks whether all constraints and
consistency checks hold among tunnel configuration parameters at the
various end points.
A capability to verify L3 reachability within a VPN MUST be provided
for diagnostic purposes.
A capability to verify the parameter configuration of a device
supporting an L3VPN MUST be provided for diagnostic purposes.
7.2. Configuration Management
Overall, the NMS must support a configuration necessary to realize
the desired L3-reachability of an L3VPN. Toward this end, an NMS
MUST provide configuration management to provision at least the
following L3VPN components: PE,CE, hierarchical tunnels, access
connections, routing, and QoS, as detailed in this section. If
shared access to the Internet is provided, then this option MUST also
As VPN configuration and topology are highly dependent on a
customer's organization, provisioning systems MUST address a broad
range of customer-specific requirements. The NMS MUST ensure that
these devices and protocols are provisioned consistently and
Provisioning for adding or removing sites SHOULD be as localized and
automated as possible.
Configuration management for VPNs, according to service templates
defined by the provider MUST be supported. A service template
contains fields that, when used, yield a definite service requirement
or policy. For example, a template for an IPSec tunnel would contain
fields such as tunnel end points, authentication modes, encryption
and authentication algorithms, pre-shared keys (if any), and traffic
filters. An SLA template would contain fields such as delay, jitter,
and throughput and packet loss thresholds, as well as end points over
which the SLA has to be satisfied. In general, a customer's service
order can be regarded as a set of instantiated service templates.
This set can, in turn, be regarded as the logical service
architecture of the customer's VPN.
Service templates can also be used by the provider to define the
service architecture of the provider's own network. For example,
OSPF templates could contain fields such as the subnets that form a
particular area, the area identifier, and the area type. BGP service
template could contain fields that, when used, would yield a BGP
policy, such as for expressing a preference about an exit router for
a particular destination.
The set of service templates SHOULD be comprehensive in that it can
capture all service orders in some meaningful sense.
The provider SHOULD provide means to translate service templates into
device configurations so that associated services can be provisioned.
Finally, the approach SHOULD provide means to check whether a service
order is correctly provisioned. This would represent one method of
diagnosing configuration errors. Configuration errors can arise due
to a variety of reasons: manual configuration, intruder attacks, and
conflicting service requirements.
7.2.1. Configuration Management for PE-Based VPNs
Requirements for configuration management unique to a PE-based VPN
are as follows:
o The NMS MUST support configuration of at least the following
aspects of L3 PE routers: intranet and extranet membership, CE
routing protocol for each access connection, routing metrics, and
o The NMS SHOULD use identifiers for SPs, L3VPNs, PEs, CEs,
hierarchical tunnels, and access connections, as described in
o Tunnels MUST be configured between PE and P devices. This
requires coordination of identifiers of tunnels, hierarchical
tunnels, VPNs, and any associated service information, for
example, a QoS/SLA service.
o Routing protocols running between PE routers and CE devices MUST
be configured per VPN.
o For multicast service, multicast routing protocols MUST also be
o Routing protocols running between PE routers and between PE and P
routers MUST also be configured.
o The configuration of a PE-based L3VPN MUST be coordinated with the
configuration of the underlying infrastructure, including Layer 1
and 2 networks interconnecting components of an L3VPN.
7.2.2. Configuration Management for CE-Based VPN
Requirements for configuration management unique to a CE-based VPN
are as follows:
o Tunnels MUST be configured between CE devices. This requires
coordination of identifiers of tunnels, VPNs, and any associated
service information, for example, a QoS/SLA service.
o Routing protocols running between PE routers and CE devices MUST
be configured. For multicast service, multicast routing protocols
MUST also be configurable.
7.2.3. Provisioning Routing
A means for a service provider to provision parameters for the IGP
for an L3VPN MUST be provided. This includes link level metrics,
capacity, QoS capability, and restoration parameters.
7.2.4. Provisioning 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
manages the CE.
7.2.5. Provisioning Security Services
When a security service is requested, an SP MUST have the means to
provision the entities and associated parameters involved with the
service. For example, for IPsec service, tunnels, options, keys, and
other parameters must be provisioned at either the CE or the PE. In
the case of an intrusion detection service, the filtering and
detection rules must be provisioned on a VPN basis.
7.2.6. Provisioning VPN Resource Parameters
A service provider MUST have a means to provision resources
associated with VPN services dynamically. For example, in a PE-based
service, the number and size of virtual switching and forwarding
table instances must be provisionable.
Dynamic VPN resource assignment is crucial for coping with the
frequent change requests from customers (e.g., sites joining or
leaving a VPN), as well as for achieving scalability. The PEs SHOULD
be able to dynamically assign the VPN resources dynamically. This
capability is especially important for dial and wireless VPN
If an SP supports a "Dynamic Bandwidth management" service, then the
provisioning system MUST be able to make requested changes within the
ranges and bounds specified in the SLA. Examples of SLA parameters
are response time and probability of being able to service such a
7.2.7. Provisioning Value-Added Service Access
An L3VPN service provides controlled access between a set of sites
over a common backbone. However, many service providers also offer a
range of value-added services. (for example, Internet access,
firewall services, intrusion protection, IP telephony and IP Centrex,
application hosting, and backup). It is outside of the scope of this
document to define whether and how these different services interact
with the VPN to solve issues such as addressing, integrity, and
security. However, the VPN service MUST be able to provide access to
these various types of value-added services.
A VPN service SHOULD allow the SP to supply the customer with
different kinds of standard IP services, such as DNS, NTP, and
RADIUS, that are needed for ordinary network operation and
management. The provider SHOULD be able to provide IP services to
multiple VPN customers.
A firewall function MAY be required to restrict access to the L3VPN
from the Internet [Y.1311].
A managed firewall service MUST be carrier grade. For redundancy and
failure recovery, a means for firewall fail-over should be provided.
Managed firewall services that may be provided include dropping
specified protocol types, intrusion protection, and traffic-rate
limiting against malicious attacks.
Managed firewalls MUST be supported on a per-VPN basis, although
multiple VPNs may be supported by the same physical device (e.g., in
a PE-based solution). Managed firewalls SHOULD be provided at the
major access point(s) for the L3VPN. Managed firewall services may
be embedded in CE or PE device or implemented in standalone devices.
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.
The NMS SHOULD support collection of information necessary for
optimal allocation of IP services in response to customer orders.
Reachability to and from the Internet to sites within a VPN MUST be
configurable by an SP. This could be controlled by configuring
routing policy to control distribution of VPN routes advertised to
7.2.8. Provisioning Hybrid VPN Services
Configuration of interworking or interconnection between L3VPN
solutions SHOULD be also supported. Ensuring that security and
end-to-end QoS issues are provided consistently SHOULD be addressed.
Many service providers require collection of measurements regarding
resource usage for accounting purposes. The NMS MAY need to
correlate accounting information with performance and fault
management information to produce billing that takes into account SLA
provisions for periods of time when the SLS is not met.
An L3VPN solution MUST describe how the following accounting
functions can be provided:
- Measurements of resource utilization.
- collection of accounting information.
- storage and administration of measurements.
Some providers may require near - real time reporting of measurement
information and may offer this as part of a customer network
If an SP supports a "Dynamic Bandwidth management" service, then the
dates, times, amounts, and interval required to perform requested
bandwidth allocation change(s) MUST be traceable for monitoring and
Solutions should state compliance with accounting requirements, as
described in section 1.7 of RFC 2975 [RFC2975].
7.4. Performance Management
Performance management MUST support functions involved with
monitoring and collecting performance data for devices, facilities,
and services, as well as determining conformance to SLS, such as QoS
and availability measurements.
Performance management SHOULD also support analysis of important
aspects of an L3VPN, such as bandwidth utilization, response time,
availability, QoS statistics, and trends based on collected data.
7.4.1. Performance Monitoring
The NMS MUST monitor device behavior to evaluate performance metrics
associated with an SLA. Different measurement techniques may be
necessary depending on the service for which an SLA is provided.
Example services are QoS, security, multicast, and temporary access.
These techniques MAY be either intrusive or non-intrusive depending
on the parameters being monitored.
The NMS MUST also monitor aspects of the VPN not directly associated
with an SLA, such as resource utilization, state of devices, and
transmission facilities, as well as control of monitoring resources
such as probes and remote agents at network access points used by
customers and mobile users.
7.4.2. SLA and QoS Management Features
The NMS SHOULD support SLAs between an SP and the various VPN
customers according to the corresponding SLSes by measurement of the
indicators defined within the context of the SLA, on a regular basis.
The NMS SHOULD use the QoS parameter measurement definitions,
techniques, and methods as defined by the IETF IP Performance Metrics
(IPPM) working group for delay, loss, and delay variation.
The NMS SHOULD support allocation and measurement of end-to-end QoS
requirements to QoS parameters for one or more VPN network(s).
Devices supporting L3VPN SLAs SHOULD have real-time performance
measurements that have indicators and threshold crossing alerts.
Such thresholds should be configurable.
7.5. Security Management
The security management function of the NMS MUST include management
features to guarantee the security of devices, access connections,
and protocols within the L3VPN network(s), as well as the security of
customer data and control as described in section 6.9.
7.5.1. Resource Access Control
Resource access control determines the privileges that a user has to
access particular applications and VPN network resources. Without
such control, only the security of the data and control traffic is
protected, leaving the devices providing the L3VPN network
unprotected. Access control capabilities protect these devices to
ensure that users have access only to the resources and applications
they are authorized to use.
In particular, access to the routing and switching resources managed
by the SP MUST be tightly controlled to prevent and/or effectively
mitigate a malicious attack. More detailed requirements in this area
are described in [VPNSEC].
Authentication is the process of verifying that the sender is
actually who he or she claims to be. The NMS MUST support standard
methods for authenticating users attempting to access management
Scalability is critical, as the number of nomadic/mobile clients is
increasing rapidly. The authentication scheme implemented for such
deployments MUST be manageable for large numbers of users and VPN
Strong authentication schemes SHALL be supported to ensure the
security of both VPN access point-to-VPN access point (e.g., PE to
PE in a PE-based case) and client-to-VPN access point (e.g., CE-to-PE
in a PE-based case) communications. This is particularly important
for preventing VPN access point spoofing, a situation where an
attacker tries to convince a PE or CE that the attacker is the VPN
access point. If an attacker can convince a PE or CE device of this,
then that device will send VPN traffic to the attacker (who could
forward it to the true access point after compromising
confidentiality or integrity). In other words, a non-authenticated
VPN AP can be spoofed with a man-in-the-middle attack, because the
endpoints never verify each other. A weakly authenticated VPN AP may
be subject to such an attack. Strongly authenticated VPN APs are not
subject to such attacks, because the man-in-the-middle cannot be
authenticated as the real AP due to the strong authentication
7.6. Network Management Techniques
Each L3VPN solution approach MUST specify the management information
bases (MIB) modules for the network elements involved in L3VPN
services. This is an essential requirement in network provisioning.
The approach SHOULD identify any information not contained in a
standard MIB related to FCAPS that is necessary to meet a generic
An IP VPN (Policy) Information model, when available, SHOULD reuse
the policy information models being developed in parallel for
specific IP network capabilities [IM-REQ]. This includes the QoS
Policy Information Model [QPIM] and the IPSEC Configuration Policy
Model [IPSECIM]. The IP VPN Information model SHOULD provide the OSS
with adequate "hooks" to correlate service level specifications with
traffic data collected from network elements. The use of policies
includes rules that control corrective actions taken by OSS
components responsible for monitoring the network and ensuring that
it meets service requirements.
Additional requirements on VPN information models are given in
reference [IM-PPVPN]. In particular, an information model MUST allow
an SP to change VPN network dimensions with minimal influence on
provisioning issues. The adopted model SHOULD be applicable to both
small/medium size and large-scale L3VPN scenarios.
Some service providers MAY require systems that visually, audibly, or
logically present FCAPS information to internal operators and/or
8. Security Considerations
Security considerations occur at several levels and dimensions within
L3VPNs, as detailed within this document. This section provides a
summary with references to detailed supporting information
The requirements in this document separate traditional notions of
security requirements, such as integrity, confidentiality, and
authentication, from issues such as isolating (or separating) the
exchange of VPN data and control traffic between specific sets of
sites (as defined in sections 3.3 and 4.1). Further detail on
security requirements is given from the customer and service provider
perspectives in sections 5.9 and 6.9, respectively. Further detail
on data and control traffic isolation requirements are given from the
customer and service provider perspectives in sections 5.1 and 6.8,
Furthermore, requirements regarding management of security from a
service provider perspective are described in section 7.5.
The authors of this document would like to acknowledge the
contributions from the people who launched the work on VPN
requirements inside ITU-T SG13 and the authors of the original IP VPN
requirements and framework document [RFC2764], as well as Tom
Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau,
Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le
Garrec. The authors are also grateful to the helpful suggestions and
direction provided by the technical advisors, Alex Zinin, Scott
Bradner, Bert Wijnen, and Rob Coltun. Finally, the authors wish to
acknowledge the insights and requirements gleaned from the many
documents listed in the references section. Citations to these
documents were made only where the authors believed that additional
insight could be obtained from reading the source document.
10.1. Normative References
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol (v3)", RFC 2251, December
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks
Identifier", RFC 2685, September 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May
[RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC
3809, June 2004.
10.2. Informative References
[2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", Work in
[IM-PPVPN] Lago, P., et al., "An Information Model for Provider
Provisioned Virtual Private Networks", Work in
[IM-REQ] Iyer, M., et al., "Requirements for an IP VPN Policy
Information Model", Work in Progress.
[IPSECIM] Jason, J., "IPsec Configuration Policy Model", Work in
[CE-PPVPN] De Clercq, J., Paridaens, O., Krywaniuk, A., Wang, C.,
"An Architecture for Provider Provisioned CE-based
Virtual Private Networks using IPsec", Work in
[IPSEC-PPVPN] Gleeson, B., "Uses of IPsec with Provider Provisioned
VPNs", Work in Progress.
[L2VPN] Rosen, E., et al., "An Architecture for L2VPNs", Work
[MPLSSEC] Behringer, M., "Analysis of the Security of the MPLS
Architecture", Work in Progress.
[PPVPN-TERM] Andersson, L., Madsen, T., "PPVPN Terminology", Work in
[L3VPN-SEC] Fang, L., et al., "Security Framework for Provider
Provisioned Virtual Private Networks", Work in
[L3VPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Layer 3
Provider Provisioned Virtual Private Networks", Work in
[PPVPN-VR] Knight, P., Ould-Brahim, H., Gleeson, B., "Network
based IP VPN Architecture using Virtual Routers", Work
[QPIM] Snir, Ramberg, Strassner, Cohen and Moore, "Policy QoS
Information Model", Work in Progress.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and
A. Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, February 2000.
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction
to Accounting Management", RFC 2975, October 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J.,
Scherling, M., Quinn, B., Herzog, S., Huynh, A.,
Carlson, M., Perry, J., and S. Waldbusser, "Terminology
for Policy-Based Management", RFC 3198, November 2001.
[TE-INTERAS] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic
Engineering requirements", Work in Progress.
[VPNDISC] Squire, M. et al., "VPN Discovery Discussions and
Options", Work in Progress.
[VPNIW] Kurakami, H., et al., "Provider-Provisioned VPNs
Interworking", Work in Progress.
[VPNSEC] De Clercq, J., et al., "Considerations about possible
security extensions to BGP/MPLS VPN", Work in Progress.
[VPNTUNNEL] Worster, T., et al., "A PPVPN Layer Separation: VPN
Tunnels and Core Connectivity", Work in Progress.
[VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V.,
"Criteria for Evaluating VPN Implementation
Mechanisms", Work in Progress.
[VPN-NEEDS] Jacquenet, C., "Functional needs for the deployment of
an IP VPN service offering : a service provider
perspective", Work in Progress.
[Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS
architecture", Y.1311.1 ITU-T Recommendation, July
[Y.1311] Knightson, K. (editor), "Network based VPNs - Generic
Architecture and Service Requirements", Y.1311 ITU-T
Recommendation, March 2002.
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
Funding for the RFC Editor function is currently provided by the