5. Customer Requirements
This section captures additional requirements from a customer
5.1. VPN Membership (Intranet/Extranet)
When an extranet is formed, a customer agent from each of the
organizations first approves addition of a site to an extranet VPN as
a business decision between the parties involved. The solution
SHOULD provide a means for these organizations to control extranet
communication involving the L3VPN exchange of traffic and routing
5.2. Service Provider Independence
Customers MAY require VPN service that spans multiple administrative
domains or service provider networks. Therefore, a VPN service MUST
be able to span multiple AS and SP networks, but still act and appear
as a single, homogeneous VPN from a customer point of view.
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
multiple ASes/SPs. In this case, as well as for all kinds of multi-
AS/SP VPNs, VPN service SHOULD be able to deliver the same SLA to all
sites in a VPN regardless of the AS/SP to which it homes.
A customer requires support from an L3VPN for the following
addressing IP assignment schemes:
o Customer-assigned, non-unique, or [RFC1918] private addresses
o Globally unique addresses obtained by the customer
o Globally unique addresses statically assigned by the L3VPN service
o On-demand, dynamically assigned IP addresses (e.g., DHCP),
irrespective of whether the access is temporary (e.g., remote) or
permanent (e.g., dedicated)
In the case of combined L3VPN service with non-unique or private
addresses and Internet access, mechanisms that permit the exchange of
traffic between the customer's address space and the global unique
Internet address space MAY be supported. For example, NAT is
employed by many customers and by 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
There SHOULD be no restriction on the routing protocols used between
CE and PE routers, or between CE routers. At least the following
protocols MUST be supported: static routing, IGP protocols such as
RIP, OSPF, IS-IS, and BGP [L3VPN-FR].
5.5. Quality of Service and Traffic Parameters
QoS is expected to be an important aspect of an L3VPN service for
some customers. QoS requirements cover scenarios involving an
intranet, an extranet, and shared access between a VPN site and the
5.5.1. Application-Level QoS Objectives
A customer is concerned primarily that the L3VPN service provides his
or her applications with the QoS and level of traffic so that the
applications perform acceptably. Voice, interactive video, and
multimedia applications are expected to require the most stringent
QoS. These real-time applications are sensitive to delay, delay
variation, loss, availability, and/or reliability. Another set of
applications, including some multimedia and interactive video
applications, high-performance web browsing, and file transfer
intensive applications, requires near real time performance.
Finally, best effort applications are not sensitive to degradation,
that is they are elastic and can adapt to conditions of degraded
The selection of appropriate QoS and service type to meet specific
application requirements is particularly important to deal with
periods of congestion in an SP network. Sensitive applications will
likely select per-flow Integrated service (Intserv) with precise SLA
guarantees measured on a per-flow basis. On the other hand, non-
sensitive applications will likely rely on a Diffserv class-based
The fundamental customer application requirement is that an L3VPN
solution MUST support both the Intserv QoS model for selected
individual flows and Diffserv for aggregated flows.
A customer application SHOULD experience consistent QoS independent
of the access network technology used at different sites connected to
the same VPN.
5.5.2. DSCP Transparency
The Diffserv Code Point (DSCP) set by a user as received by the
ingress CE SHOULD be capable of being relayed transparently to the
egress CE (see section 2.6.2 of [RFC3270] and [Y.1311.1]). Although
RFC 2475 states that interior or boundary nodes within a DS domain
can change the DSCP, customer VPNs MAY have other requirements, such
o applications that use the DSCP in a manner differently from the
DSCP solution supported by the SP network(s),
o customers using more DSCPs within their sites than the SP
o support for a carrier's carrier service in which one SP is the
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
mapping solution supported by the carrier's carrier SP.
Note that support for DSCP transparency has no implication on the QoS
or SLA requirements. If an SP supports DSCP transparency, then that
SP needs to carry only the DSCP values across its domain but MAY map
the received DSCP to some other value for QoS support across its
5.6. Service-Level Specification/Agreement
Most customers simply want their applications to perform well. An
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.
Therefore, when purchasing service under an SLA, a customer agent
MUST have access to the measures from the SP(s) that support the SLA.
5.7. Customer Management of a VPN
A customer MUST have a means to view the topology, operational state,
order status, and other parameters associated with his or her VPN.
Most aspects of management information about CE devices and customer
attributes of an L3VPN manageable by an SP SHOULD be capable of being
configured and maintained by an authenticated, authorized customer
agent. However, some aspects, such as encryption keys, SHALL NOT be
readable nor writable by management systems.
A customer agent SHOULD be able to make dynamic requests for changes
to traffic parameters. A customer SHOULD be able to receive real-
time response from the SP network in response to these requests. One
example of such service is a "Dynamic Bandwidth management"
capability that enables real-time response to customer requests for
changes of allocated bandwidth allocated to his or her VPN
A customer who may not be able to afford the resources to manage his
own sites SHOULD be able to outsource the management of the entire
VPN to the SP(s) supporting the VPN network.
These features include traffic and routing information exchange
isolation, similar to that obtained in VPNs based on Layer 1 and
Layer 2 (e.g., private lines, FR, or ATM) [MPLSSEC].
The suite of L3VPN solutions SHOULD support a range of security
related features. Higher levels of security services, such as edge-
to-edge encryption, authentication, or replay attack, should be
supported. More details on customer requirements for security are
described in [VPNSEC].
Security in an L3VPN service SHOULD be as transparent as possible to
the customer, with the obvious exception of support for remote or
temporary user access, as detailed in section 5.11.2.
L3VPN customers MUST be able to deploy their own internal security
mechanisms in addition to those deployed by the SP, in order to
secure specific applications or traffic at a granularity finer than
that on a site-to-site basis.
If a customer requires QoS support in an L3VPN, then this request
MUST be communicated to the SP either by using unencrypted fields or
via an agreed security association. For example, applications could
send RSVP messages in support of Intserv either in the clear or
encrypted with a key negotiated with the SP. Another case is that
where applications using an IPsec tunnel could copy the DSCP from the
encrypted IP header to the header of the tunnel's IP header.
5.10. Migration Impact
Often, customers are migrating from an already deployed private
network toward one or more L3VPN solutions. A typical private
network scenario is CE routers connected via real or virtual
circuits. Ideally, minimal incremental cost SHOULD result during the
migration period. Furthermore, if necessary, any disruption of
service SHOULD also be minimized.
A range of scenarios of customer migration MUST be supported. Full
migration of all sites MUST be supported. Support for cases of
partial migration is highly desirable [Y.1311.1] - that is, legacy
private network sites that belong to the L3VPN service SHOULD still
have L3 reachability to the sites that migrate to the L3VPN service.
5.11. Network Access
Every L3 packet exchanged between the customer and the SP over the
access connection MUST appear as it would on a private network
providing an equivalent service to that offered by the L3VPN.
5.11.1. Physical/Link Layer Technology
L3VPNs SHOULD support a broad range of physical and link-layer access
technologies, such as PSTN, ISDN, xDSL, cable modem, leased line,
Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop, and
mobile radio access. The capacity and QoS achievable may be
dependent on the specific access technology in use.
5.11.2. Temporary Access
The VPN service offering SHOULD allow both permanent and temporary
access to one or more L3VPNs for authenticated users across a broad
range of access technologies. Support for remote or temporary VPN
access SHOULD include ISDN, PSTN dial-in, xDSL, or access via another
SP network. The customer SHOULD be able to choose from alternatives
for authentication of temporary access users. Choices for access
authentication are SP-provided, third-party, or customer-provided
A significant number of VPN users may not be permanently attached to
one VPN site: in order to limit access to a VPN to authorized users,
it is first necessary to authenticate them. Authentication 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 function
SHOULD be used to invoke all actions necessary to join a user to the
A user SHOULD be able to access an L3VPN via a network having generic
Mobile users may move within an L3VPN site. Mobile users may also
have temporary connections to different L3VPN sites within the same
VPN. Authentication SHOULD be provided in both of these cases.
5.11.3. Sharing of the Access Network
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 the
access network is the responsibility of the L3VPN customer.
5.11.4. Access Connectivity
Various types of physical connectivity scenarios MUST be supported,
such as multi-homed sites, backdoor links between customer sites, and
devices homed to two or more SP networks. L3VPN solutions SHOULD
support at least the types of physical or link-layer connectivity
arrangements shown in Figure 2.1. Support for other physical
connectivity scenarios with arbitrary topology is desirable.
Access arrangements with multiple physical or logical paths from a CE
to other CEs and PEs MUST support redundancy and SHOULD support load
balancing. Resiliency uses redundancy to provide connectivity
between a CE site and other CE sites and, optionally, other services.
Load balancing provides a means to perform traffic engineering so
that capacity on redundant links is used to achieve improved
performance during periods when the redundant component(s) are
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
(a), load balancing SHOULD be provided by the two PEs over the two
links connecting to the single CE. In case (c), load balancing
SHOULD be provided by the two PEs over the two links connecting to
the two CEs.
In addition, the load-balancing parameters (e.g., the ratio of
traffic on the multiple load-balanced links, or the preferred link)
SHOULD be provisionable based on customer's requirements. The load-
balancing capability may also be used to achieve resiliency in the
event of access connectivity failures. For example, in case (b) a CE
may connect to two different SPs via diverse access networks.
Resiliency MAY be further enhanced as shown in case (d), where CEs
connected via a "back door" connection connect to different SPs.
Furthermore, arbitrary combinations of the above methods, with a few
examples shown in cases (e) and (f), should be supportable by any
For multi-homing to multiple SPs, load balancing capability MAY also
be supported by the PEs in the different SPs (clearly, this is a more
complex type of load balancing to realize, requiring policy and
service agreements between the SPs to interoperate).
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |router| |device| |router| SP network
+------+\\ +------+ +------+\\ +------+
| \\ | | \\ |
|Back \\ | |Back \\
|door \\ | SP network |door \\
|link \\ | |link \\ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+
Figure 2.1. Representative types of access arrangements5.12. Service Access
Customers MAY also require access to other services, as described in
5.12.1. Internet Access
Customers SHOULD be able to have L3VPN and Internet access across 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
sites in the L3VPN to one or more customer sites that have firewalls,
other security-oriented devices, and/or NATs that process all traffic
between the Internet and the customer's VPN.
L3 VPN Customers SHOULD be able to receive traffic from the Internet
addressed to a publicly accessible resource that is not part of the
VPN, such as an enterprise's public web server.
As stated in section 5.3, if a customer L3VPN employs private or
non-unique IP addresses, then network address translation (NAT) or a
similar mechanism MUST be provided either by the customer or the SP
in order to allow traffic exchange with devices outside the
5.12.2. Hosting, Application Service Provider
A customer SHOULD be able to access hosting, other application
services, or other Application Service Providers (ASP) over an L3
L3VPN service. This MAY require that an ASP participate in one or
more VPNs with the customers that use such a service.
5.12.3. Other Services
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,
VoIP, NAT, LDAP, Videoconferencing, Application sharing, E-business,
Streaming, E-commerce, Directory, Firewall, etc. The resources that
implement these services could be physically dedicated to each VPN.
If the resources are logically shared, then they MUST have access
separated and isolated between VPNs in a manner consistent with the
L3VPN solution to meet this requirement.
5.13. Hybrid VPN Service Scenarios
Intranet or extranet customers have a number of reasons for wanting
hybrid networks that involve more than one VPN solution type. These
include migration, mergers, extranet customers with different VPN
types, the need for different capabilities between different sets of
sites, temporary access, and different availability of VPN solutions
as provided by different service providers.
The framework and solution approaches SHOULD include provisions for
interworking, interconnection, and/or reachability between different
L3VPN solutions in a way that does not overly complicate
provisioning, management, scalability, or performance.
6. Service Provider Network Requirements
This section describes requirements from a service provider
[RFC3809] lists projections of L3VPN sizing and scalability
requirements and metrics related to specific solutions.
As described in section 4.2, SPs MUST have support for public and
private IP addresses, IPv4 and IPv6, for both unicast and multicast.
In order to support this range of addressing schemes, SPs require the
following support from L3VPN solutions.
An L3VPN solution MUST be able to assign blocks of addresses from its
own public IP address space to L3VPN customer sites so that
advertisement of routes to other SPs and other sites aggregates
An L3VPN solution MUST be able to use address assignments made by a
customer. These customer-assigned addresses may be public or
If private IP addresses are used, an L3VPN solution MUST provide a
means for an SP to translate such addresses to public IP addresses
for communication with other VPNs by using overlapping addresses or
A number of identifiers MAY be necessary for SP use in management,
control, and routing protocols. Requirements for at least the
following identifiers are known.
An SP domain MUST be uniquely identified at least within the set of
all interconnected SP networks when supporting a VPN that spans
multiple SPs. Ideally, this identifier should be globally unique
(e.g., an AS number).
An identifier for each VPN SHOULD be unique, at least within each
SP's network. Ideally, the VPN identifier SHOULD be globally unique
to support the case where a VPN spans multiple SPs (e.g., [RFC2685]).
A CE device SHOULD have a unique identifier, at least within each
A PE device SHOULD have a unique identifier, at least within each
The identifier of a device interconnecting SP networks MUST be unique
within the set of aforementioned networks.
Each site interface SHOULD have a unique identifier, at least within
each PE router supporting such an interface.
Each tunnel SHOULD have a unique identifier, at least within each
router supporting the tunnel.
6.4. Discovering VPN Related Information
Configuration of CE and PE devices is a significant task for a
service provider. Solutions SHOULD strive to contain methods that
dynamically allow VPN information to be discovered (or learned) by
the PE and/or CE to reduce configuration complexity. The following
specific requirements apply to intra- and inter-provider VPNs
Every device involved in a VPN SHALL be able to identify and
authenticate itself to other devices in the VPN. After learning the
VPN membership, the devices SHOULD be able to exchange configuration
information securely. The VPN information MUST include at least the
IP address of the PE and may be extensible to provide additional
Each device in a VPN SHOULD be able to determine which other devices
belong to the same VPN. Such a membership discovery scheme MUST
prevent unauthorized access and allow authentication of the source.
Distribution of VPN information SHOULD be limited to those devices
involved in that VPN.
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
VPN network is correctly configured.
The mechanism SHOULD respond to VPN membership changes in a timely
manner. This is no longer than the provisioning timeframe, typically
on the order of minutes, and could be as short as the timeframe
required for "rerouting", typically on the order of seconds.
Dynamically creating, changing, and managing multiple VPN assignments
to sites and/or customers is another aspect of membership that MUST
be addressed in an L3VPN solution.
6.5. SLA and SLS Support
Typically, a Service Provider offering an L3VPN service commits to
specific Service Level Specifications (SLS) as part of a contract
with the customer, as described in section 4.4 and [RFC3809]. Such a
Service Level Agreement (SLA) implies SP requirements for measuring
Specific Service Level Specifications (SLS) for quality,
availability, response time, and configuration intervals.
6.6. Quality of Service (QoS) and Traffic Engineering
A significant aspect of an L3VPN is support for QoS. Since an SP has
control over the provisioning of resources and configuration of
parameters in at least the PE and P devices and, in some cases, in
the 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 section 4.3.2.
Each L3VPN approach MUST describe the traffic engineering techniques
available for an SP to meet the QoS objectives. These descriptions
of traffic engineering techniques SHOULD quantify scalability and
achievable efficiency. Traffic engineering support MAY be on an
aggregate or per-VPN basis.
QoS policies MUST not be impacted by security mechanisms. For
example, Diffserv policies MUST not be impacted by the use of IPSec
tunnels using the mechanisms explained in RFC 2983 [RFC2983].
As stated in RFC 2475, a mapping function from customer provided
Diffserv marking to marking used in an SP network should be provided
for L3 VPN services.
If a customer requires DSCP transparency, as described in section
5.5.2, an L3VPN service MUST deliver the same value of DSCP field in
the IP header received from the customer to the egress demarcation of
The distribution of reachability and routing policy SHOULD be
constrained to the sites that are members of the VPN.
Optionally, the exchange of such information MAY use some form of
authentication (e.g., MD5).
Functions to isolate the SP network and customer VPNs from anomalous
routing behavior from a specific set of customer sites SHOULD be
provided. Examples of such functions are controls for route flap
dampening, filters that accept only prefixes configured for a
specific CE, a maximum number of routes accepted for each CE, or a
maximum rate at which route updates can be received from a CE.
When VPN customers use overlapping non-unique IP addresses, the
solution MUST define a means to distinguish between such overlapping
addresses on a per-VPN basis.
Furthermore, the solution SHOULD provide an option that either allows
or prevents advertisement of VPN routes to the Internet.
Ideally, the choice of an SP's IGP SHOULD not depend on the routing
protocol(s) used between PE and CE routers in a PE-based VPN.
Furthermore, it is desirable that an SP SHOULD have a choice
regarding the IGP routing protocol.
The additional routing burden that an SP must carry should be
articulated in each specific L3VPN solution.
6.8. Isolation of Traffic and Routing
The internal structure of an L3VPN network SHOULD not be visible to
outside networks (e.g., the Internet or any connected VPN).
From a high-level SP perspective, a PE-based L3VPN MUST isolate the
exchange of traffic and routing information to only those sites that
are authenticated and authorized members of a VPN.
In a CE-based VPN, the tunnels that connect the sites effectively
meet this isolation requirement if both traffic and routing
information flow over the tunnels.
An L3VPN solution SHOULD provide a means to meet L3VPN QoS SLA
requirements that isolates VPN traffic from the effects of traffic
offered by non-VPN customers. Also, L3VPN solutions SHOULD provide a
means to isolate the effects that traffic congestion produced by
sites as part of one VPN can have on another VPN.
This section contains requirements related to securing customer
flows; providing authentication services for temporary, remote, or
mobile users; and protecting service provider resources involved in
supporting an L3VPN. More detailed security requirements are
provided in [VPNSEC].
6.9.1. Support for Securing Customer Flows
In order to meet the general requirement for providing a range of
security options to a customer, each L3VPN solution MUST clearly
spell out the configuration options that can work together and how
they can do so.
When a VPN solution operates over a part of the Internet, it should
support a configurable option to support one or more of the following
standard IPsec methods for securing a flow for a specified subset of
a customer's VPN traffic:
o Confidentiality, so that only authorized devices can decrypt it
o Integrity, to ensure that the data has not been altered
o Authentication, to ensure that the sender is indeed who he or she
claims to be
o Replay attack prevention.
The above functions SHOULD be applicable to "data traffic" of the
customer, which includes the traffic exchanged between sites between
temporary users and sites, and even between temporary users. It
SHOULD also be possible to apply these functions to "control
traffic", such as routing protocol exchanges, that are not
necessarily perceived by the customer but are nevertheless essential
to maintain his or her VPN.
Furthermore, such security methods MUST be configurable between
different end points, such as CE-CE, PE-PE, and CE-PE. It is also
desirable to configure security on a per-route or per-VPN basis
A VPN solution MAY support one or more encryption schemes, including
AES, and 3DES. Encryption, decryption, and key management SHOULD be
included in profiles as part of the security management system.
6.9.2. Authentication Services
A service provider MUST provide authentication services in support of
temporary user access requirements, as described in section 5.11.2.
Furthermore, traffic exchanged within the scope of VPN MAY involve
several categories of equipment that must cooperate to provide the
service [Y.1311.1]. These network elements can be CE, PE, firewalls,
backbone routers, servers, management stations, etc. These network
elements learn about each other's identity, either via manual
configuration or via discovery protocols, as described in section
6.4. When network elements must cooperate, these network elements
SHALL authenticate peers before providing the requested service.
This authentication function MAY also be used to control access to
The peer identification and authentication function described above
applies only to network elements participating in the VPN. Examples
- traffic between a CE and a PE,
- traffic between CEs belonging to the same VPN,
- CE or PE routers dealing with route announcements for a VPN,
- policy decision point [RFC3198] and a network element, and
- management station and an SNMP agent.
For a peer authentication function, each L3VPN solution SHOULD
describe where necessary, how it shall be implemented, how secure it
must be, and the way to deploy and maintain identification and
authentication information necessary to operate the service.
6.9.3. Resource Protection
Recall from the definitions in section 3.3 that a site can be part of
an intranet with sites from the only same organization, can be part
of an extranet involving sites from other organizations, can have
access to the Internet, or can have any combination of these scopes
of communication. Within these contexts, a site might be subject to
various attacks coming from different sources. Potential sources of
- users connected to the supporting public IP backbone,
- users from the Internet, and
- users from temporary sites belonging to the intranet and/or
extranet VPN the site is part of.
Security threats and risks that a site may encounter include the
- Denial of service, for example mail spamming, access connection
congestion, TCP SYN attacks, and ping attacks
- Intrusion attempts, which may eventually lead to denial of service
(e.g., a Trojan horse attack).
Additional threat scenarios are defined in [VPNSEC]. An L3VPN
solution MUST state how it addresses each potential threat scenario.
The devices in the L3VPN network must provide some means of reporting
intrusion attempts to the service provider resources.
6.10. Inter-AS (SP)VPNs
The scenario for VPNs spanning multiple Autonomous Systems (AS) or
Service Providers (SP) requires standard solutions. The scenario
where multiple ASes are involved is the most general case and is
therefore the one described here. The scenarios of concern are the
CE-based and PE-based L3VPNs defined in section 3.
In each scenario, all applicable SP requirements, such as traffic and
routing isolation, SLAs, management, security, and provisioning.
MUST be preserved across adjacent ASes. The solutions MUST describe
the inter-SP network interface, encapsulation method(s), routing
protocol(s), and all applicable parameters [VPNIW].
An essential pre-condition for an inter-AS VPN is an agreement
between the ASes involved that spells out at least trust, economic,
and management responsibilities.
The overall scalability of the VPN service MUST allow the L3VPN
service to be offered across potentially hundreds of SPs, with the
overall scaling parameters per SP given in [RFC3809].
6.10.1. Routing Protocols
If the link between ASes is not trusted, routing protocols running
between those ASes MUST support some form of authentication. For
example, the TCP option for carrying an MD5 digest may be used to
enhance security for BGP [RFC2385].
BGP MUST be supported as the standard inter-AS routing protocol to
control the path taken by L3VPN traffic.
The general requirements for managing a single AS apply to a
concatenation of ASes. A minimum subset of such capabilities as
- Diagnostic tools (e.g., ping, traceroute)
- Secured access to one AS management system by another
- Configuration request and status query tools
- Fault notification and trouble-tracking tools
6.10.3. Bandwidth and QoS Brokering
When a VPN spans multiple ASes, a brokering mechanism is desired that
requests certain SLA parameters, such as bandwidth and QoS, from the
other domains and/or networks involved in transferring traffic to
various sites. Although bandwidth and QoS brokering across multiple
ASes is not common in today's networks, these may be desirable for
maintaining 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 ASes can establish and guarantee uniform QoS in support of
The brokering mechanism can be a manual one, for example, in which
one provider requests from another a specific set of bandwidth and
QoS parameters for traffic going to and from a specific set of sites.
The mechanism could also be an automated one where a device
dynamically requests and receives certain bandwidth and SLA/QoS
parameters. For instance, in the case of an L3VPN over MPLS, a PE
may negotiate the label for different traffic classes to reach a PE
residing in a neighboring AS. Or, it might be a combination of both.
For additional detailed requirements on the automated approach, see
Brokering on a per VPN basis is not desirable as this approach would
not scale. A solution MUST provide some means to aggregate QoS and
bandwidth brokering requests between ASes. One method could be for
SPs to make an agreement specifying the maximum amount of bandwidth
for specific QoS parameters for all VPN customers using the SP
network. Alternatively, such aggregation might be on a per
hierarchical tunnel basis between PE routers in different ASes
supporting an L3VPN service [TE-INTERAS].
6.10.4. Security Considerations
If a tunnel traverses multiple SP networks and passes through an
unsecured SP, POP, NAP, or IX, then security mechanisms MUST be
employed. These security mechanisms include encryption,
authentication, and resource protection, as described in section 6.9,
and security management, as covered in section 7.5. For example, a
provider should consider using both authentication and encryption for
a tunnel used as part of an L3VPN that traverses another service
6.11. L3VPN Wholesale
The architecture MUST support the possibility of one service provider
offering VPN service to another service provider. Another example is
when one service provider sells L3VPN service at wholesale to another
service provider, who then resells that VPN service to his or her
The wholesaler's VPN MUST be transparent to the addressing and
routing used by the reseller.
Support for additional levels of hierarchy (for example, three levels
at which a reseller can again resell the VPN service to yet another
VPN provider) SHOULD be provided.
The Carrier's Carrier scenario is the term used in this document for
this category of L3VPN wholesale (although some scenarios of Inter-
AS/Inter-Provider VPN could possibly fall in this L3VPN wholesale
category, too). Various carrier's carrier scenarios should be
supported, such as when
- the customer carriers do not operate L3VPN services for their
- the customer carriers operate L3VPN services for their clients,
but these services are not linked with the L3VPN service offered
by the Carrier's Carrier and
- the customer carriers operate L3VPN services for their clients,
and these services are linked with the L3VPN service offered by
the Carrier's Carrier ("Hierarchical VPNs" scenario).
6.12. Tunneling Requirements
Connectivity between CE sites or PE devices in the backbone SHOULD
use a range of tunneling technologies, such as L2TP, IPSEC, GRE, IP-
in-IP, and MPLS.
To set up tunnels between routers, every router MUST support static
configuration for tunneling and MAY support a tunnel setup protocol.
If employed, a tunnel establishment protocol SHOULD be capable of
conveying information such as the following:
- Relevant identifiers
- QoS/SLA parameters
- Restoration parameters
- Multiplexing identifiers
- Security parameters
There MUST be a means to monitor the following aspects of tunnels:
- Statistics, such as amount of time spent in the up and down state.
- Count of transitions between the up and down state.
- Events, such as transitions between the up and down states.
The tunneling technology used by the VPN Service Provider and its
associated mechanisms for tunnel establishment, multiplexing, and
maintenance MUST meet the requirements on scaling, isolation,
security, QoS, manageability, etc.
6.13. Support for Access and Backbone Technologies
This section describes requirements for aspects of access and
backbone network technologies from an SP point of view.
Some SPs MAY desire that a single network infrastructure suffices for
all services, public IP, VPNs, traffic engineering, and
differentiated services [L2VPN].
6.13.1. Dedicated Access Networks
Ideally, the L3VPN service SHOULD be independent of physical, link
layer, or even network technology of the access network. However,
the characteristics of access networks MUST be accounted for when the
QoS aspects of SLAs for VPN service offerings are specified.
6.13.2. On-Demand Access Networks
Service providers SHOULD be able to support temporary user access, as
described in section 5.11.2, by using dedicated or dial-in access
L3VPN solutions MUST support the case where a VPN user directly
accesses the VPN service through an access network connected to the
service provider. They MUST also describe how they can support the
case where one or more other service provider networks are used for
access to the service provider supporting the L3VPN service.
Ideally, all information necessary to identify and authenticate users
for an intranet SHOULD be stored and maintained by the customer. In
an extranet, one customer SHOULD be able to maintain the
authentication server, or the customers involved in the extranet MAY
choose to outsource the function to a service provider.
Identification and authentication information could be made available
to the service provider for controlling access, or the service
provider may query a customer maintained server. Furthermore, one SP
may act as access for the SP providing the VPN service. If the
access SP performs identification and authentication on behalf of the
VPN SP, an agreement MUST be reached on a common specification.
Support for at least the following authentication protocols SHALL be
supported: PAP, CHAP, and EAP, as they are currently used in a wide
range of equipment and services.
6.13.3. Backbone Networks
Ideally, the backbone interconnecting SP, PE, and P devices SHOULD be
independent of physical and link layer technology. Nevertheless, the
characteristics of backbone technology MUST be taken into account
when specifying the QoS aspects of SLAs for VPN service offerings.
6.14. Protection, Restoration
When primary and secondary access connections are available, an L3VPN
solution MUST provide restoration of access connectivity whenever the
primary access link from a CE site to a PE fails. This capability
SHOULD be as automatic as possible, that is, the traffic should be
directed over the secondary link soon after failure of the primary
access link is detected. Furthermore, reversion to the primary link
SHOULD be dynamic, if configured to do so [VPN-NEEDS].
As mentioned in section 5.11.4, in the case of multi-homing, 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 (but not all) of
the multi-homed links, the load balancing parameters MAY be
dynamically adjusted to redirect the traffic rapidly from the failed
link(s) to the surviving links. Once the failed link(s) is (are)
restored, the original provisioned load balancing ratio SHOULD be
restored to its value prior to the failure.
An SP SHOULD be able to deploy protection and restoration mechanisms
within his or her backbone infrastructure to increase reliability and
fault tolerance of the VPN service offering. These techniques SHOULD
be scalable, and therefore should strive not to perform such function
in the backbone on a per-VPN basis.
Appropriate measurements and alarms that indicate how well network
protection and restoration mechanisms are performing MUST be
Service providers are interested in interoperability in at least the
- Facilitating use of PE and managed CE devices within a single SP
- Implementing L3VPN services across two or more interconnected SP
- Achieving interworking or interconnection between customer sites
using different L3VPN approaches or different implementations of
the same approach.
Each approach MUST describe whether any of the above objectives can
be met. If an objective can be met, the approach MUST describe how
such interoperability could be achieved. In particular, the approach
MUST describe the inter-solution network interface, encapsulation
method(s), routing protocol(s), security, isolation, management, and
all other applicable aspects of the overall VPN solution provided
6.16. Migration Support
Service providers MUST have a graceful means to migrate a customer
with minimal service disruption on a site-by-site basis to an L3VPN
If L3VPN approaches can interwork or interconnect, then service
providers MUST have a graceful means to migrate a customer with
minimal service disruption on a site-by-site basis whenever
interworking or interconnection is changed.