| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | Tunnel | |VFI of| | conn. | of |
|VPN A|----------|VPN A |==================|VPN A |----------|VPN A|
+-----+ | +------+ | | +------+ | +-----+
| | | |
+-----+ Access | +------+ | | +------+ | Access +-----+
|CE | conn. | |VFI of| | Tunnel | |VFI of| | conn. | CE |
| dev |----------|VPN B |==================|VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 1.1. PE Usage of Separate Tunnels to Support VPNs
Figure 1.2 illustrates the case where a single hierarchical tunnel is
used between PE devices to support communication for VPNs. The
innermost encapsulating protocol header provides the means for the PE
to determine the VPN for which the packet is directed.
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | | |VFI of| | conn. | of |
|VPN A|----------|VPN A | | Hierarchical | |VPN A |----------|VPN A|
+-----+ | +------+\| Tunnel |/+------+ | +-----+
| >==============< |
+-----+ Access | +------+/| |\+------+ | Access +-----+
| CE | conn. | |VFI of| | | |VFI of| | conn. | CE |
| dev |----------|VPN B | | | |VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 1.2. PE Usage of Shared Hierarchical Tunnels to Support VPNs
3.6.2. CE-Based L3VPN Tunnel Endpoints and Functions
Figure 1.3 illustrates the CE-based L3VPN reference model. In this
configuration, typically a single level of tunnel (e.g., IPsec)
terminates at pairs of CEs. Usually, a CE serves a single customer
site, and therefore the forwarding and routing is physically separate
from all other customers. Furthermore, the PE is not aware of the
membership of specific CE devices to a particular VPN. Hence, the
VPN functions are implemented with provisioned configurations on the
CE devices, and the shared PE and P network is used to only provide
the routing and forwarding that supports the tunnel endpoints on
between CE devices. The tunnel topology connecting the CE devices
may be a full or partial mesh, depending on VPN customer requirements
and traffic patterns.
+---------+ +--------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ Tunnel |router| |device| : | of |
| of |=:================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |device| | | : |
| CE | : | | Tunnel +------+ : +------+
|device|=:================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +----------+ +----------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | |management| |management| | | : |
|interface| | | function | | function | | |Customer |
| | | +----------+ +----------+ | |interface|
| | | | | |
+---------+ +--------------------------------+ +---------+
| Access | |<-------- SP network(s) ------->| | Access |
| network | | | | network |
Figure 1.3. CE-Based L3VPN
3.7. Customer and Provider Network Management
Customer Network Management Function: A customer network management
function provides the means for a customer agent to query or
configure customer-specific information, or to receive alarms
regarding his or her VPN. Customer-specific information includes
data related to contact, billing, site, access network, IP address,
and routing protocol parameters. It may use a combination of
proprietary network management system, SNMP manager, or directory
service (e.g., LDAP [RFC3377] [RFC2251]).
Provider Network Management Function: A provider network management
function provides many of the same capabilities as a customer network
management system across all customers. This would not include
customer confidential information, such as keying material. The
intent of giving the provider a view comparable to that of the
customer is to aid in troubleshooting and problem resolution. Such a
system also provides the means to query, configure, or receive alarms
regarding any infrastructure supporting the L3VPN service. It may
use a combination of proprietary network management system, SNMP
manager, or directory service (e.g., LDAP [RFC3377] [RFC2251]).
4. Service Requirements Common to Customers and Service Providers
Many of the requirements that apply to both the customer and the
provider and are of an otherwise general nature, or that apply to
both L2 and L3VPNs, are described in [RFC3809]. This section
contains requirements that are not covered in [RFC3809] and that are
specific to L3VPNs.
4.1. Isolated Exchange of Data and Routing Information
A mechanism must be provided for isolating the distribution of
reachability information to only those sites associated with a VPN.
L3VPN solutions shall define means that prevent routers in a VPN from
interacting with unauthorized entities and that avoid introducing
undesired routing information that could corrupt the VPN routing
information base [VPN-CRIT].
A means must be provided to constrain or isolate the distribution of
addressed data to only those VPN sites determined by either routing
data and/or configuration.
A single site shall be capable of being in multiple VPNs. The VPN
solution must ensure that traffic is exchanged only with sites in the
same VPN.
The internal structure of a VPN should not be advertised or
discoverable from outside that VPN.
Note that isolation of forwarded data or exchange of reachability
information to only those sites that are part of a VPN may be viewed
as a form of security - for example, [Y.1311.1], [MPLSSEC].
4.2. Addressing
IP addresses must be unique within the set of sites reachable from
the VPNs of which a particular site is a member.
A VPN solution must support IPv4 and IPv6 as both the encapsulating
and encapsulated protocol.
If a customer has private or non-unique IP addresses, then a VPN
service SHOULD be capable of translating such customer private or
non-unique IP addresses for communicating with IP systems having
public addresses.
4.3. Quality of Service
To the extent possible, L3VPN QoS should be independent of the access
network technology.
4.3.1. QoS Standards
A non-goal of the L3VPN WG effort (as chartered) is the development
of new protocols or extension of existing ones. An L3VPN shall be
able to support QoS in one or more of the following already defined
modes:
- Best Effort (mandatory support for all L3VPN types)
- Aggregate CE Interface Level QoS ("hose" level QoS)
- Site-to-site ("pipe" level QoS)
- Intserv (i.e., RSVP) signaled
- Diffserv marked
- Across packet-switched access networks
Note that all cases involving QoS may require that the CE and/or PE
perform shaping and/or policing.
L3VPN CEs should be capable of supporting integrated services
(Intserv) for certain customers in support of session applications,
such as switched voice or video. Intserv-capable CE devices shall
support the following Internet standards:
- Resource reSerVation Protocol (RSVP) [RFC2205]
- Guaranteed Quality of Service providing a strict delay bound
[RFC2212]
- Controlled Load Service providing performance equivalent to that
of an unloaded network [RFC2211]
L3VPN CE and PE should be capable of supporting differentiated
service (Diffserv). Diffserv-capable L3VPN CE and PE shall support
the following per hop behavior (PHB) [RFC2475] types:
- Expedited Forwarding (EF) - The departure rate of an aggregate
class of traffic from a device that must equal or exceed a
configured rate [RFC3246].
- Assured Forwarding (AF) - A means for a provider Diffserv (DS)
domain to offer different levels of forwarding assurances for IP
packets received from a customer DS domain. Four AF classes are
defined, where each AF class implies allocation in each DS node of
a certain amount of forwarding resources (e.g., buffer space and
bandwidth) [RFC2597].
A CE or PE device supporting an L3VPN service may classify a packet
for a particular Intserv or Diffserv service based on one or more of
the following IP header fields: protocol ID, source port number,
destination port number, destination address, or source address.
For a specifiable set of Internet traffic, L3VPN devices should
support Random Early Detection (RED) to provide graceful degradation
in the event of network congestion.
4.3.2. Service Models
A service provider must be able to offer QoS service to a customer
for at least the following generic service types: managed-access VPN
service or edge-to-edge QoS VPN service [RFC3809]. More detail
specific to L3VPNs is provided below.
A managed-access L3VPN service provides QoS on the access 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 PE router.
Note that this service would not require Diffserv implementation in
the SP backbone. The SP may use policing for inbound traffic at the
PE. The CE may perform shaping for outbound traffic. Another
example of a managed-access L3VPN service is when the SP performs the
packet classification and diffserv marking. An SP may provide
several packet classification profiles that customers may select or
may offer custom profiles based on customer specific requirements.
In general, more complex QoS policies should be left to the customer
for implementation.
An edge-to-edge QoS VPN service provides QoS from edge device to edge
device. The edge device may be either PE or CE, depending on the
service demarcation point between the provider and the customer.
Such a service may be provided across one or more provider backbones.
The CE requirements for this service model are the same as the
managed access VPN service. However, in this service QoS is provided
from one edge of the SP network(s) to the other.
4.4. Service-Level Specification and Agreements
A generic discussion of SLAs is provided in [RFC3809]. Additionally,
SLS measurements for quality based on the DiffServ scheme SHOULD be
based on the following classification:
- A Point-to-Point SLS [Y.1311.1], sometimes also referred to as
the "Pipe" model, defines traffic parameters in conjunction
with the QoS objectives for traffic exchanged between a pair
of VPN sites (i.e., points). A Point-to-Point SLS is
analogous to the SLS typically supported over point-to-point
Frame Relay or ATM PVCs or an edge-to-edge MPLS tunnel. The
set of SLS specifications to all other reachable VPN sites
would define the overall Point-to-Point SLS for a specific
site.
- A Point-to-Cloud SLS [Y.1311.1], sometimes also referred to as
the "Hose" model, defines traffic parameters in conjunction
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
other sites in the VPN (i.e., the cloud), as applicable. In
other words, a point-to-cloud SLS defines compliance in terms
of all packets transmitted from a given VPN site toward the SP
network on an aggregate basis (i.e., regardless of the
destination VPN site of each packet).
- A Cloud-to-Point SLS (a case not covered by this SLS is where
flows originating from multiple sources may congest the
interface toward a specific site).
Traffic parameters and actions SHOULD be defined for packets to and
from the demarcation between the service provider and the site. For
example, policing may be defined on ingress, and shaping on egress.
4.5. Management
An SP and its customers MUST be able to manage the capabilities and
characteristics of their VPN services. To the extent possible,
automated operations and interoperability with standard management
platforms SHOULD be supported.
The ITU-T Telecommunications Management Network (TMN) model has the
following generic requirements structure:
O Engineer, deploy, and manage the switching, routing, and
transmission resources supporting the service, from a network
perspective (network element management).
O Manage the VPN networks deployed over these resources (network
management).
o Manage the VPN service (service management).
o Manage the VPN business, mainly provisioning administrative and
accounting information related to the VPN service customers
(business management).
Service management should include the TMN ’FCAPS’ functionalities, as
follows: Fault, Configuration, Accounting, Provisioning, and
Security, as detailed in section 7.
4.6. Interworking
Interworking scenarios among different solutions providing L3VPN
services is highly desirable. See the L3VPN framework document for
more details on interworking scenarios [L3VPN-FR]. Interworking
SHOULD be supported in a scalable manner.
Interworking scenarios MUST at least consider traffic and routing
isolation, security, QoS, access, and management aspects. This
requirement is essential of network migration, to ensure service
continuity among sites belonging to different portions of the
network.
5. Customer Requirements
This section captures additional requirements from a customer
perspective.
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
information.
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.
5.3. Addressing
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
provider
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
Internet.
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
performance.
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
QoS.
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
as
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
network(s) supports,
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
domain.
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
[Y.1311.1].
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.
5.8. Isolation
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].
5.9. Security
The suite of L3VPN solutions SHOULD support a range of security