Request for Comments: 4665 Y. Serbest, Ed.
Category: Informational AT&T
September 2006
Service Requirements for Layer 2
Provider-Provisioned Virtual Private Networks
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides requirements for Layer 2 Provider-Provisioned
Virtual Private Networks (L2VPNs). It first provides taxonomy and
terminology and states generic and general service requirements. It
covers point-to-point VPNs, referred to as Virtual Private Wire
Service (VPWS), as well as multipoint-to-multipoint VPNs, also known
as Virtual Private LAN Service (VPLS). Detailed requirements are
expressed from both a customer as well as a service provider
perspectives.
Table of Contents
1. Introduction ....................................................4
1.1. Scope of This Document .....................................4
1.2. Outline ....................................................5
2. Conventions used in this document ...............................5
3. Contributing Authors ............................................5
4. Definitions and Taxonomy ........................................5
4.1. Definitions ................................................5
4.2. Taxonomy of L2VPN Types ....................................6
4.3. VPWS .......................................................6
4.4. VPLS .......................................................7
5. Service Requirements Common to Customers and Service Providers ..7
5.1. Scope of emulation .........................................8
5.2. Traffic Types ..............................................8
5.3. Topology ...................................................8
5.4. Isolated Exchange of Data and Forwarding Information .......9
5.5. Security ...................................................9
5.5.1. User Data Security .................................10
5.5.2. Access Control .....................................10
5.6. Addressing ................................................11
5.7. Quality of Service ........................................11
5.7.1. QoS Standards ......................................11
5.7.2. Service Models .....................................11
5.8. Service Level Specifications ..............................12
5.9. Protection and Restoration ................................12
5.10. CE-to-PE and PE-to-PE Link Requirements ..................12
5.11. Management ...............................................12
5.12. Interoperability .........................................12
5.13. Inter-working ............................................13
6. Customer Requirements ..........................................13
6.1. Service Provider Independence .............................13
6.2. Layer 3 Support ...........................................13
6.3. Quality of Service and Traffic Parameters .................14
6.4. Service Level Specification ...............................14
6.5. Security ..................................................14
6.5.1. Isolation ..........................................14
6.5.2. Access Control .....................................14
6.5.3. Value-Added Security Services ......................15
6.6. Network Access ............................................15
6.6.1. Physical/Link Layer Technology .....................15
6.6.2. Access Connectivity ................................15
6.7. Customer Traffic ..........................................17
6.7.1. Unicast, Unknown Unicast, Multicast, and
Broadcast forwarding ...............................17
6.7.2. Packet Re-ordering .................................17
6.7.3. Minimum MTU ........................................17
6.7.4. End-point VLAN Tag Translation .....................18
6.7.5. Transparency .......................................18
6.8. Support for Layer 2 Control Protocols .....................18
6.9. CE Provisioning ...........................................19
7. Service Provider Network Requirements ..........................19
7.1. Scalability ...............................................19
7.1.1. Service Provider Capacity Sizing Projections .......19
7.1.2. Solution-Specific Metrics ..........................19
7.2. Identifiers ...............................................19
7.3. Discovering L2VPN Related Information .....................19
7.4. Quality of Service (QoS) ..................................20
7.5. Isolation of Traffic and Forwarding Information ...........20
7.6. Security ..................................................21
7.7. Inter-AS/SP L2VPNs ........................................22
7.7.1. Management .........................................22
7.7.2. Bandwidth and QoS Brokering ........................22
7.8. L2VPN Wholesale ...........................................23
7.9. Tunneling Requirements ....................................23
7.10. Support for Access Technologies ..........................23
7.11. Backbone Networks ........................................24
7.12. Network Resource Partitioning and Sharing Between
L2VPNs ...................................................24
7.13. Interoperability .........................................24
7.14. Testing ..................................................25
7.15. Support on Existing PEs ..................................25
8. Service Provider Management Requirements .......................26
9. Engineering Requirements .......................................26
9.1. Control Plane Requirements ................................26
9.2. Data Plane Requirements ...................................27
9.2.1. Encapsulation ......................................27
9.2.2. Responsiveness to Congestion .......................27
9.2.3. Broadcast Domain ...................................27
9.2.4. Virtual Switching Instance .........................27
9.2.5. MAC Address Learning ...............................27
10. Security Considerations .......................................28
11. Acknowledgements ..............................................28
12. References ....................................................29
12.1. Normative References .....................................29
12.2. Informative References ...................................29
1. Introduction
This section describes the scope and outline of the document.
1.1. Scope of This Document
This document provides requirements for provider-provisioned Layer 2
Virtual Private Networks (L2VPN). It identifies requirements that
MAY apply to one or more individual approaches that a Service
Provider (SP) may use for the provisioning of a Layer 2 VPN service.
The content of this document makes use of the terminology defined in
[RFC4026] and common components for deploying L2VPNs described in
[RFC4664].
The technical specifications to provide L2VPN services are outside
the scope of this document. The framework document [RFC4664] and
several other documents, which explain technical approaches providing
L2VPN services, such as [VPLS_LDP], [VPLS_BGP], and [IPLS], are
available to cover this aspect.
This document describes requirements for two types of L2VPNs: (1)
Virtual Private Wire Service (VPWS), and (2) Virtual Private LAN
Service (VPLS). The approach followed in this document distinguishes
L2VPN types as to how the connectivity is provided (point-point or
multipoint-multipoint), as detailed in [RFC4664].
This document is intended as a "checklist" of requirements that will
provide a consistent way to evaluate and document how well each
individual approach satisfies specific requirements. The
applicability statement document for each individual approach should
document the results of this evaluation.
In the context of provider-provisioned VPNs, there are two entities
involved in operation of such services, the Provider and the
Customer. The Provider engages in a binding agreement with the
Customer as to the behavior of the service in a normal situation as
well as in exceptional situations. Such agreement is known as
Service Level Specification (SLS), which is part of the Service Level
Agreement (SLA) established between the Provider and the Customer.
A proper design of L2VPNs aids formulation of SLSes in that it
provides means for proper separation between Customer Edge (CE) and
Provider Edge (PE), allows proper execution of the SLS offer, and
supports a flexible and rich set of capabilities.
This document provides requirements from both the Provider’s and the
Customer’s point of view. It begins with common customer’s and
service provider’s point of view, followed by a customer’s
perspective, and concludes with specific needs of an SP. These
requirements provide high-level L2VPN features expected by an SP in
provisioning L2VPNs, which include SP requirements for security,
privacy, manageability, interoperability, and scalability.
1.2. Outline
The outline of the rest of this document is as follows. Section 4
provides definitions and taxonomy. Section 5 provides common
requirements that apply to both customer and SP, respectively.
Section 6 states requirements from a customer perspective. Section 7
states network requirements from an SP perspective. Section 8 states
SP management requirements. Section 9 describes the engineering
requirements, particularly control and data plane requirements.
Section 10 provides security considerations. Section 11 lists
acknowledgements. Section 12 provides a list of references cited
herein.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Contributing Authors
This document was the combined effort of several individuals. The
following are the authors that contributed to this document:
Waldemar Augustyn
Marco Carugi
Giles Heron
Vach Kompella
Marc Lasserre
Pascal Menezes
Hamid Ould-Brahim
Tissa Senevirathne
Yetik Serbest
4. Definitions and Taxonomy
4.1. Definitions
The terminology used in this document is defined in [RFC4026]. The
L2VPN framework document [RFC4664] further describes these concepts
in the context of a reference model that defines layered service
relationships between devices and one or more levels of tunnels.
4.2. Taxonomy of L2VPN Types
The requirements distinguish two major L2VPN models, a Virtual
Private Wire Service (VPWS), and a Virtual Private LAN Service
(VPLS).
The following diagram shows an L2VPN reference model.
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ........................ | +-----+
L2VPN A | +----+ +----+ | L2VPN A
+--| PE |--- Service ---| PE |--+
+----+ Provider +----+
/ . Backbone . \ - /\-_
+-----+ / . | . \ / \ / \ +-----+
+ CE4 +--+ . | . +--\ Access \----| CE5 |
+-----+ . +----+ . | Network | +-----+
L2VPN B .........| PE |......... \ / L2VPN B
+----+ ^ -------
| |
| |
+-----+ |
| CE3 | +-- Logical switching instance
+-----+
L2VPN A
Figure 1. L2VPN Reference Model
4.3. VPWS
The PE devices provide a logical interconnect such that a pair of CE
devices appears to be connected by a single logical Layer 2 circuit.
PE devices act as Layer 2 circuit switches. Layer 2 circuits are
then mapped onto tunnels in the SP network. These tunnels can either
be specific to a particular VPWS, or be shared among several
services. VPWS applies for all services, including Ethernet, ATM,
Frame Relay, etc. In Figure 1, L2VPN B represents a VPWS case.
Each PE device is responsible for allocating customer Layer 2 frames
to the appropriate VPWS and for proper forwarding to the intended
destinations.
4.4. VPLS
In case of VPLS, the PE devices provide a logical interconnect such
that CE devices belonging to a specific VPLS appear to be connected
by a single LAN. End-to-end VPLS consists of a bridge module and a
LAN emulation module ([RFC4664]). A VPLS can contain a single VLAN
or multiple VLANs ([IEEE_802.1Q]). A variation of this service is
IPLS ([RFC4664]), which is limited to supporting only customer IP
traffic.
In a VPLS, a customer site receives Layer 2 service from the SP. The
PE is attached via an access connection to one or more CEs. The PE
performs forwarding of user data packets based on information in the
Layer 2 header, such as a MAC destination address. In Figure 1,
L2VPN A represents a VPLS case.
The details of VPLS reference model, which we summarize here, can be
found in [RFC4664]. In VPLS, the PE can be viewed as containing a
Virtual Switching Instance (VSI) for each L2VPN that it serves. A CE
device attaches, possibly through an access network, to a bridge
module of a PE. Within the PE, the bridge module attaches, through
an Emulated LAN Interface to an Emulated LAN. For each VPLS, there
is an Emulated LAN instance. The Emulated LAN consists of VPLS
Forwarder module (one per PE per VPLS service instance) connected by
pseudo wires (PW), where the PWs may be traveling through Packet
Switched Network (PSN) tunnels over a routed backbone. VSI is a
logical entity that contains a VPLS forwarder module and part of the
bridge module relevant to the VPLS service instance [RFC4664].
Hence, the VSI terminates PWs for interconnection with other VSIs and
also terminates Attachment Circuits (ACs) (see [RFC3985] for
definition) for accommodating CEs. A VSI includes the forwarding
information base for an L2VPN [RFC4664] which is the set of
information regarding how to forward Layer 2 frames received over the
AC from the CE to VSIs in other PEs supporting the same L2VPN service
(and/or to other ACs), and it contains information regarding how to
forward Layer 2 frames received from PWs to ACs. Forwarding
information bases can be populated dynamically (such as by source MAC
address learning) or statically (e.g., by configuration). Each PE
device is responsible for proper forwarding of the customer traffic
to the appropriate destination(s) based on the forwarding information
base of the corresponding VSI.
5. Service Requirements Common to Customers and Service Providers
This section contains requirements that apply to both the customer
and the provider, or that are of an otherwise general nature.
5.1. Scope of emulation
L2VPN protocols SHOULD NOT interfere with existing Layer 2 protocols
and standards of the Layer 2 network the customer is managing. If
they impact customer Layer 2 protocols that are sent over the VPLS,
then these impacts MUST be documented.
Some possibly salient differences between VPLS and a real LAN are:
- The reliability may likely be less, i.e., the probability that a
message broadcast over the VPLS is not seen by one of the bridge
modules in PEs is higher than in a true Ethernet.
- VPLS frames can get duplicated if the PW sequencing option isn’t
turned on. The data frames on the PWs are sent in IP datagrams,
and under certain failure scenarios, IP networks can duplicate
packets. If the PW data transmission protocol does not ensure
sequence of data packets, frames can be duplicated or received out
of sequence. If the customer’s Bridge Protocol Data Unit (BPDU)
frames are sent as data packets, then BPDU frames can be duplicated
or mis-sequenced, although this may not create any problems for
Real-Time Streaming Protocol (RSTP).
- Delayed delivery of packets (e.g., more than half a second), rather
than dropping them, could have adverse effect on the performance of
the service.
- 802.3x Pause frames will not be transported over a VPLS, as the
bridge module ([RFC4664]) in the PE terminates them.
- Since the IPLS solution aims at transporting encapsulated traffic
(rather than Layer 2 frames themselves), the IPLS solution is NOT
REQUIRED to preserve the Layer 2 Header transparently from CE to
CE. For example, Source MAC address will probably not be preserved
by the IPLS solution.
5.2. Traffic Types
A VPLS MUST support unicast, multicast, and broadcast traffic.
Support for efficient replication of broadcast and multicast traffic
is highly desirable.
5.3. Topology
A SP network may be realized using one or more network tunnel
topologies to interconnect PEs, ranging from simple point-to-point to
distributed hierarchical arrangements. The typical topologies
include:
- Point-to-point
- Point-to-multipoint, a.k.a. hub and spoke
- Any-to-any, a.k.a. full mesh
- Mixed, a.k.a. partial mesh
- Hierarchical
Regardless of the SP topology employed, the service to the customers
MUST retain the connectivity type implied by the type of L2VPN. For
example, a VPLS MUST allow multipoint-to-multipoint connectivity even
if it is implemented with point-to-point circuits. This requirement
does not imply that all traffic characteristics (such as bandwidth,
QoS, delay, etc.) necessarily be the same between any two end points
of an L2VPN. It is important to note that SLS requirements of a
service have a bearing on the type of topology that can be used.
To the extent possible, an L2VPN service SHOULD be capable of
crossing multiple administrative boundaries.
To the extent possible, the L2VPN services SHOULD be independent of
access network technology.
5.4. Isolated Exchange of Data and Forwarding Information
L2VPN solutions SHALL define means that prevent CEs in an L2VPN from
interaction with unauthorized entities.
L2VPN solutions SHALL avoid introducing undesired forwarding
information that could corrupt the L2VPN forwarding information base.
A means to constrain or isolate the distribution of addressed data to
only those VPLS sites determined either by MAC learning and/or
configuration MUST be provided.
The internal structure of an L2VPN SHOULD not be advertised or
discoverable from outside that L2VPN.
5.5. Security
A range of security features MUST be supported by the suite of L2VPN
solutions. Each L2VPN solution MUST state which security features it
supports and how such features can be configured on a per-customer
basis.
A number of security concerns arise in the setup and operation of an
L2VPN, ranging from misconfigurations to attacks that can be launched
on an L2VPN and can strain network resources such as memory space,
forwarding information base table, bandwidth, and CPU processing.
This section lists some potential security hazards that can result
due to mis-configurations and/or malicious attacks. There MUST be
methods available to protect against the following situations.
- Protocol attacks
o Excessive protocol adjacency setup/teardown
o Excessive protocol signaling/withdrawal
- Resource Utilization
o Forwarding plane replication (VPLS)
o Looping (VPLS primarily)
o MAC learning table size limit (VPLS)
- Unauthorized access
o Unauthorized member of VPN
o Incorrect customer interface
o Incorrect service delimiting VLAN tag
o Unauthorized access to PE
- Tampering with signaling
o Incorrect FEC signaling
o Incorrect PW label assignment
o Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.)
- Tampering with data forwarding
o Incorrect MAC learning entry
o Incorrect PW label
o Incorrect AC identifier
o Incorrect customer facing encapsulation
o Incorrect PW encapsulation
o Hijacking PWs using the wrong tunnel
o Incorrect tunnel encapsulation
5.5.1. User Data Security
An L2VPN solution MUST provide traffic separation between different
L2VPNs.
In case of VPLS, VLAN Ids MAY be used as service delimiters. When
used in this manner, they MUST be honored and traffic separation MUST
be provided.
5.5.2. Access Control
An L2VPN solution MAY also have the ability to activate the
appropriate filtering capabilities upon request of a customer.
5.6. Addressing
An L2VPN solution MUST support overlapping addresses of different
L2VPNs. For instance, customers MUST NOT be prevented from using the
same MAC addresses with different L2VPNs. If a service provider uses
VLANs as service delimiters, the L2VPN solution MUST ensure that VLAN
Ids cannot overlap. If VLANs are not used as service delimiters,
L2VPN solutions MAY allow VLAN Ids to overlap.
5.7. Quality of Service
To the extent possible, L2VPN QoS SHOULD be independent of the access
network technology.
5.7.1. QoS Standards
As provided in [RFC3809], an L2VPN SHALL be able to support QoS in
one or more of the following already standardized modes:
- Best Effort (support mandatory for all provider-provisioned
VPN types)
- Aggregate CE Interface Level QoS (i.e., ’hose’ level)
- Site-to-site, or ’pipe’ level QoS
Note that all cases involving QoS MAY require that the CE and/or PE
perform shaping and/or policing.
Mappings or translations of Layer 2 QoS parameters into PSN QoS
(e.g., DSCPs or MPLS EXP field) as well as QoS mapping based on VC
(e.g., FR/ATM or VLAN) MAY be performed in order to provide QoS
transparency. The actual mechanisms for these mappings or
translations are outside the scope of this document. In addition,
the Diffserv support of underlying tunneling technologies (e.g.,
[RFC3270] or [RFC3308]) and the Intserv model ([RFC2205]) MAY be
used. As such, the L2VPN SLS requirements SHOULD be supported by
appropriate core mechanisms.
5.7.2. Service Models
A service provider may desire to offer QoS service to a customer for
at least the following generic service types: managed access VPN
service or an edge-to-edge QoS service. The details of the service
models can be found in [RFC3809] and in [RFC4031].
In L2VPN service, both DSCP ([RFC2474]) and 802.1p ([IEEE_802.1D])
fields may be used for this purpose.
5.8. Service Level Specifications
For an L2VPN service, the capabilities for Service Level
Specification (SLS) monitoring and reporting stated in [RFC3809]
SHOULD be provided.
5.9. Protection and Restoration
The L2VPN service infrastructure SHOULD provide redundant paths to
ensure high availability. The reaction to failures SHOULD result in
an attempt to restore the service using alternative paths.
The intention is to keep the restoration time small. The restoration
time MUST be less than the time it takes the CE devices, or customer
Layer 2 control protocols as well as Layer 3 routing protocols, to