detect a failure in the L2VPN.
5.10. CE-to-PE and PE-to-PE Link Requirements
The CE-to-PE links MAY be
- direct physical links (e.g., 100BaseTX, and T1/E1 TDM),
- logical links (e.g., ATM PVC, and RFC2427-encapsulated link),
- transport networks carrying Ethernet,
- a Layer 2 tunnel that goes through a Layer 3 network (e.g., L2TP
sessions).
Layer 2 frames MAY be tunneled through a Layer 3 backbone from PE to
PE, using one of a variety of tunneling technologies (e.g., IP-in-IP,
GRE, MPLS, L2TP, etc.).
5.11. Management
Standard interfaces to manage L2VPN services MUST be provided (e.g.,
standard SNMP MIB Modules). These interfaces SHOULD provide access
to configuration, verification and runtime monitoring protocols.
Service management MAY include the TMN ’FCAPS’ functionalities, as
follows: Fault, Configuration, Accounting, Performance, and Security,
as detailed in [ITU_Y.1311.1].
5.12. Interoperability
Multi-vendor interoperability, which corresponds to similar network
and service levels among different implementations, at the network
element SHOULD be guaranteed. This will likely rely on the
completeness of the corresponding standard.
The technical solution MUST be multi-vendor interoperable, not only
within the SP network infrastructure, but also with the customer’s
network equipment and services making use of the L2VPN service.
A L2VPN solution SHOULD NOT preclude different access technologies.
For instance, customer access connections to an L2VPN service MAY be
different at different CE devices (e.g., Frame Relay, ATM, 802.1D,
MPLS).
5.13. Inter-working
Inter-working scenarios among different solutions providing L2VPN
services are highly desirable. It is possible to have cases that
require inter-working or interconnection between customer sites,
which span network domains with different L2VPN solutions or
different implementations of the same approach. Inter-working SHOULD
be supported in a scalable manner.
Inter-working scenarios MUST consider at least traffic isolation,
security, QoS, access, and management aspects. This requirement is
essential in the case of network migration, to ensure service
continuity among sites belonging to different portions of the
network.
6. Customer Requirements
This section captures requirements from a customer perspective.
6.1. Service Provider Independence
Customers MAY require L2VPN service that spans multiple
administrative domains or SP networks. Therefore, an L2VPN service
MUST be able to span multiple AS and SP networks but still to act and
to appear as a single, homogeneous L2VPN from a customer point of
view.
A customer might also start with an L2VPN provided in a single AS
with a certain SLS but then ask for an expansion of the service
spanning multiple ASes and/or multiple-SPs. In this case, as well as
for all kinds of multi-AS and multiple-SP L2VPNs, L2VPN service
SHOULD be able to deliver the same SLS to all sites in a VPN
regardless of the AS/SP to which it homes.
6.2. Layer 3 Support
With the exception of IPLS, an L2VPN service SHOULD be agnostic to
customer’s Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated
within Layer 2 frames.
IPLS MUST allow transport of customer’s IPv4 and IPv6 traffic
encapsulated within Layer 2 frames. IPLS SHOULD also allow CEs to
run ISIS and MPLS protocols transparently among them when those are
used in conjunction with IP.
6.3. Quality of Service and Traffic Parameters
QoS is expected to be an important aspect of an L2VPN service for
some customers.
A customer requires that the L2VPN service provide the QoS applicable
to his or her application, which can range from PWs (e.g., SONET
emulation) to voice, interactive video, and multimedia applications.
Hence, best-effort as well as delay and loss sensitive traffic MUST
be supported over an L2VPN service. A customer application SHOULD
experience consistent QoS independent of the access network
technology used at different sites connected to the same L2VPN.
6.4. Service Level Specification
Most customers simply want their applications to perform well. A SLS
is a vehicle for a customer to measure the quality of the service
that SP(s) provide. Therefore, when purchasing a service, a customer
requires access to the measures from the SP(s) that support the SLS.
Standard interfaces to monitor usage of L2VPN services SHOULD be
provided (e.g., standard SNMP MIB Modules).
6.5. Security
6.5.1. Isolation
An L2VPN solution MUST provide traffic as well as forwarding
information base isolation for customers similar to that obtained in
private lines, FR, or ATM services.
An L2VPN service MAY use customer VLAN Ids as service delimiters. In
that case, they MUST be honored, and traffic separation MUST be
provided.
6.5.2. Access Control
An L2VPN solution MAY have the mechanisms to activate the appropriate
filtering capabilities upon request of a customer. For instance, MAC
and/or VLAN filtering MAY be considered between CE and PE for a VPLS.
6.5.3. Value-Added Security Services
An L2VPN solution MAY provide value-added security services such as
encryption and/or authentication of customer packets, certificate
management, and similar services.
L2VPN services MUST NOT interfere with the security mechanisms
employed at Layer 3 and higher layers by customers. Layer 2 security
mechanisms, such as 802.10b ([IEEE_802.10]) and 802.1AE
([IEEE_802.1AE]), MAY inhibit L2VPN services, when the service
delimiting VLAN Ids are encrypted.
6.6. Network Access
Every 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 L2VPN.
6.6.1. Physical/Link Layer Technology
L2VPN solutions 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, mobile radio access, etc. The capacity and QoS
achievable MAY be dependent on the specific access technology in use.
6.6.2. 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. In case of VPLS, IEEE
802.3ad-2000 link aggregation SHOULD be supported. L2VPN solutions
SHOULD support at least the types of physical or link-layer
connectivity arrangements shown in Figures 2 - 4 (in addition to the
case shown in Figure 1). As in Figure 2, a CE can be dual-homed to
an SP or to two different SPs via diverse access networks.
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 2. Dual-Homed Access of CE Devices
Resiliency of the L2VPN service can be further enhanced as shown in
Figure 3, where CE’s connected via a "back door" connection, connect
to the same SP or to different SPs.
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 3. Backdoor Links Between CE Devices
Arbitrary combinations of the above methods, with a few examples
shown in Figure 4, SHOULD be supported by any L2VPN solution.
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+\ +------+ +------+\ +------+
| \ | | \ |
|Back \ | |Back \ +-------------
|door \ | SP network |door \ +-------------
|link \ | |link \ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 4. Combination of Dual-Homing and
Backdoor Links for CE Devices
6.7. Customer Traffic
6.7.1. Unicast, Unknown Unicast, Multicast, and Broadcast forwarding
A VPLS MUST deliver every packet at least to its intended
destination(s) within the scope of the VPLS, subject to the ingress
policing and security policies.
6.7.2. Packet Re-ordering
During normal operation, the queuing and forwarding policies SHOULD
preserve packet order for packets with the same QoS parameters.
6.7.3. Minimum MTU
A VPLS MUST support the theoretical MTU of the offered service.
The committed minimum MTU size MUST be the same for a given VPLS
instance. Different L2VPN services MAY have different committed MTU
sizes. If the customer VLANs are used as service delimiters, all
VLANs within a given VPLS MUST inherit the same MTU size.
A VPLS MAY use IP fragmentation if it presents reassembled packets at
VPLS customer edge devices.
6.7.4. End-point VLAN Tag Translation
The L2VPN service MAY support translation of customers’ AC
identifiers (e.g., VLAN tags, if the customer VLANs are used as
service delimiters). Such service simplifies connectivity of sites
that want to keep their AC assignments or sites that belong to
different administrative domains. In the latter case, the
connectivity is sometimes referred to as Layer 2 extranet. On the
other hand, it should be noted that VLAN tag translation affects the
support for multiple spanning trees (i.e., 802.1s [IEEE_802.1s]) and
can break the proper operation.
6.7.5. Transparency
The L2VPN service is intended to be transparent to Layer 2 customer
networks. An L2VPN solution SHOULD NOT require any special packet
processing by the end users before sending packets to the provider’s
network.
If VLAN Ids are assigned by the SP, then VLANs are not transparent.
Transparency does not apply in this case, as it is the same as FR/ATM
service model.
Since the IPLS solution aims at transporting encapsulated traffic
(rather than Layer 2 frames themselves), the IPLS solution MUST not
alter the packets encapsulated inside Layer 2 frames that are
transported by the IPLS. However, the IPLS solution is NOT REQUIRED
to preserve the Layer 2 header transparently from CE to CE. For
example, Source MAC address might not be preserved by the IPLS
solution. The IPLS solution MAY remove Layer 2 headers for transport
over the backbone when those can be reconstructed on egress without
compromising transport of encapsulated traffic.
6.8. Support for Layer 2 Control Protocols
The L2VPN solution SHOULD allow transparent operation of Layer 2
control protocols employed by customers.
In case of VPLS, the L2VPN service MUST ensure that loops be
prevented. This can be accomplished with a loop-free topology or
appropriate forwarding rules. Control protocols such as Spanning
Tree (STP) or similar protocols could be employed. The L2VPN
solution MAY use indications from customer Layer 2 control protocols,
e.g., STP BPDU snooping, to improve the operation of a VPLS.
6.9. CE Provisioning
The L2VPN solution MUST require only minimal or no configuration on
the CE devices, depending on the type of CE device that connects into
the infrastructure.
7. Service Provider Network Requirements
This section describes requirements from an SP perspective.
7.1. Scalability
This section contains projections regarding L2VPN sizing and
scalability requirements and metrics specific to particular
solutions.
7.1.1. Service Provider Capacity Sizing Projections
[RFC3809] lists projections regarding L2VPN sizing and scalability
requirements and metrics. The examples are provided in [RFC3809].
7.1.2. Solution-Specific Metrics
Each L2VPN solution SHALL document its scalability characteristics in
quantitative terms.
7.2. Identifiers
An SP domain MUST be uniquely identified at least within the set of
all interconnected SP networks when supporting an L2VPN that spans
multiple SPs. Ideally, this identifier SHOULD be globally unique
(e.g., an AS number).
An identifier for each L2VPN SHOULD be unique, at least within each
SP’s network, as it MAY be used in auto-discovery, management (e.g.,
alarm and service correlation, troubleshooting, performance
statistics collection), and signaling. Ideally, the L2VPN identifier
SHOULD be globally unique to support the case, where an L2VPN spans
multiple SPs (e.g., [RFC2685]). Globally unique identifiers
facilitate the support of inter-AS/SP L2VPNs.
7.3. Discovering L2VPN Related Information
Configuration of PE devices (i.e., U-PE and N-PE [RFC4664]) is a
significant task for an SP. Solutions SHOULD provide methods that
dynamically allow L2VPN information to be discovered by the PEs to
minimize the configuration steps.
Each device in an L2VPN SHOULD be able to determine which other
devices belong to the same L2VPN. Such a membership discovery scheme
MUST prevent unauthorized access, and it allows authentication of the
source.
Distribution of L2VPN information SHOULD be limited to those devices
involved in that L2VPN. An L2VPN solution SHOULD employ discovery
mechanisms to minimize the amount of operational information
maintained by the SPs. For example, if an SP adds or removes a
customer port on a given PE, the remaining PEs SHOULD determine the
necessary actions to take without the SP’s having to explicitly
reconfigure those PEs.
A L2VPN solution SHOULD support the means for attached CEs to
authenticate each other and to verify that the SP L2VPN is correctly
connected.
The mechanism SHOULD respond to L2VPN membership changes in a timely
manner. A "timely manner" is no longer than the provisioning
timeframe, typically on the order of minutes, and MAY be as short as
the timeframe required for "rerouting," typically on the order of
seconds.
Dynamically creating, changing, and managing multiple L2VPN
assignments to sites and/or customers is another aspect of membership
that MUST be addressed in an L2VPN solution.
7.4. Quality of Service (QoS)
A significant aspect of a provider-provisioned VPN is support for
QoS. 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 the CE devices as well. Therefore, the SP is to provide
either managed QoS access service, or edge-to-edge QoS service, as
defined in [RFC4031].
7.5. Isolation of Traffic and Forwarding Information
From a high level SP perspective, an L2VPN MUST isolate the exchange
of traffic and forwarding information to only those sites that are
authenticated and authorized members of an L2VPN.
An L2VPN solution SHOULD provide a means for meeting provider-
provisioned VPN QoS SLS requirements that isolates L2VPN traffic from
the affects of traffic offered by non-VPN customers. Also, L2VPN
solutions SHOULD provide a means so that traffic congestion produced
by sites as part of one L2VPN does not affect another L2VPN.
7.6. Security
The security requirements are stated in Section 6.5. The security
requirements provided in [RFC3809] SHOULD be met. The security
requirements, except Layer 3 and higher-layer dependent ones,
specified in [RFC4031], SHOULD be met.
In addition, an SP network MUST be protected against malformed or
maliciously constructed customer traffic. This includes but is not
limited to duplicate or invalid Layer 2 addresses, customer side
loops, short/long packets, spoofed management packets, spoofed VLAN
tags, high volume traffic.
The SP network devices MUST NOT be accessible from any L2VPN, unless
specifically authorized. The devices in the SP network SHOULD
provide some means of reporting intrusion attempts to the SP, if the
intrusion is detected.
When an L2VPN 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 customer’s VPN
traffic:
- Confidentiality, so that only authorized devices can decrypt it
- Integrity, to ensure that the data has not been altered
- Authentication, to ensure that the sender is indeed who he or she
claims to be
- Replay attack prevention.
The above functions SHOULD be applicable to "data traffic" of the
customer, which includes the traffic exchanged between sites. It
SHOULD also be possible to apply these functions to "control
traffic", such as routing or signaling protocol exchanges, that is
not necessarily perceived by the customer but is nevertheless
essential to maintain his or her VPN.
Furthermore, such security methods MUST be configurable between
different end-points, such as PE-PE and PE-MTU, only in the case
where L2VPN data traffic is carried over IP [RFC4023]. Methods to
secure data flows at the native service layer (Layer-2), from CE-CE,
CE-MTU and CE-PE, are outside the scope of this document. It is also
desirable to configure security on a 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.
7.7. Inter-AS/SP L2VPNs
All applicable SP requirements, such as traffic and forwarding
information isolation, SLSes, management, security, provisioning,
etc. MUST be preserved across adjacent ASes. The solution MUST
describe the inter-SP network interface, encapsulation method(s),
routing protocol(s), and all applicable parameters.
An L2VPN solution MUST provide the specifics of offering L2VPN
services spanning multiple ASes and/or SPs.
An L2VPN solution MUST support proper dissemination of operational
parameters to all elements of an L2VPN service in the presence of
multiple ASes and/or SPs. A L2VPN solution MUST employ mechanisms
for sharing operational parameters between different ASes.
An L2VPN solution SHOULD support policies for proper selection of
operational parameters coming from different ASes. Similarly, an
L2VPN solution SHOULD support policies for selecting information to
be disseminated to different ASes.
7.7.1. Management
The general requirements for managing a single AS apply to a
concatenation of ASes. A minimum subset of such capabilities is the
following:
- Diagnostic tools
- Secured access to one AS management system by another
- Configuration request and status query tools
- Fault notification and trouble tracking tools
7.7.2. Bandwidth and QoS Brokering
When an L2VPN spans multiple ASes, there is a need for a brokering
mechanism that requests certain SLS parameters, such as bandwidth and
QoS, from the other domains and/or networks involved in transferring
traffic to various sites. The essential requirement is that a
solution MUST be able to determine whether a set of ASes can
establish and guarantee uniform QoS in support of a provider-
provisioned VPN.
7.8. L2VPN Wholesale
The architecture MUST support the possibility of one SP’s offering