INTERNET DRAFT W. Augustyn
Internet Engineering Task Force
Document: Y. Serbest
draft-ietf-l2vpn-requirements-01.txt SBC
February 2004 (Editors)
Category: Informational
Expires: August 2004
Service Requirements for Layer-2 Provider Provisioned Virtual Private
Networks
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 ([RFC2026]).
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document provides requirements for Provider Provisioned Layer-2
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 a customer as well as a service provider perspective.
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]).
Table of Contents
1 Contributing Authors..............................................4
2 Introduction......................................................4
[Page 1]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
2.1Scope of this document...........................................4
2.2Outline..........................................................5
3 Definitions and Taxonomy..........................................5
3.1Definitions......................................................5
3.2Taxonomy of L2VPN Types..........................................5
3.3VPWS.............................................................6
3.4VPLS.............................................................6
4 Service Requirements Common to Customers and Service Providers....7
4.1Scope of emulation...............................................7
4.2Traffic Types....................................................7
4.3Topology.........................................................7
4.4Isolated Exchange of Data and Forwarding Information.............8
4.5Security.........................................................8
4.5.1 User data security........................................9
4.5.2 Access control............................................9
4.6Addressing.......................................................9
4.7Quality of Service..............................................10
4.7.1 QoS Standards............................................10
4.7.2 Service Models...........................................10
4.8Service Level Specifications....................................10
4.9Protection and Restoration......................................10
4.10 CE-to-PE and PE-to-PE link requirements.......................10
4.11 Management....................................................11
4.12 Interoperability..............................................11
4.13 Inter-working.................................................11
5 Customer Requirements............................................11
5.1Service Provider Independence...................................11
5.2Layer-3 Support.................................................12
5.3Quality of Service and Traffic Parameters.......................12
5.4Service Level Specification.....................................12
5.5Security........................................................12
5.5.1 Isolation................................................12
5.5.2 Access control...........................................13
5.5.3 Value added security services............................13
5.6Network Access..................................................13
5.6.1 Physical/Link Layer Technology...........................13
5.6.2 Access Connectivity......................................13
5.7Customer traffic................................................15
5.7.1 Unicast, Unknown Unicast, Multicast, and Broadcast
forwarding.......................................................15
5.7.2 Packet Re-ordering.......................................15
5.7.3 Minimum MTU..............................................15
5.7.4 End-point VLAN tag translation...........................15
5.7.5 Transparency.............................................15
5.8Support for Layer-2 Control Protocols...........................16
5.9CE Provisioning.................................................16
6 Service Provider Network Requirements............................16
6.1Scalability.....................................................16
6.1.1 Service Provider Capacity Sizing Projections.............16
6.1.2 Solution-Specific Metrics................................17
6.2Identifiers.....................................................17
6.3Discovering L2VPN Related Information...........................18
[Page 2]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
6.4SLS Support.....................................................18
6.5Quality of Service (QoS)........................................18
6.6Isolation of Traffic and Forwarding Information.................18
6.7Security........................................................19
6.8Inter-AS/SP L2VPNs..............................................19
6.8.1 Management...............................................19
6.8.2 Bandwidth and QoS Brokering..............................20
6.9L2VPN Wholesale.................................................20
6.10 Tunneling Requirements........................................20
6.11 Support for Access Technologies...............................20
6.12 Backbone Networks.............................................21
6.13 Network Resource Partitioning and Sharing Between L2VPNs......21
6.14 Interoperability..............................................21
6.15 Testing.......................................................22
6.16 Support on Existing PEs.......................................22
7 Service Provider Management Requirements.........................22
8 Engineering Requirements.........................................22
8.1Control Plane Requirements......................................22
8.2Data Plane Requirements.........................................23
8.2.1 Encapsulation............................................23
8.2.2 Responsiveness to Congestion.............................23
8.2.3 Broadcast Domain.........................................23
8.2.4 Virtual Switching Instance...............................23
8.2.5 MAC address learning.....................................24
9 Security Considerations..........................................24
10 Acknowledgments..................................................24
11 References.......................................................24
11.1 Normative References..........................................24
11.2 Informative References........................................25
12 Editors' Addresses...............................................25
[Page 3]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
1 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
2 Introduction
This section describes the scope and outline of the document.
2.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
[VPN_TERM] and common components for deploying L2VPNs described in
[L2VPN_FR].
The technical specifications to provide L2VPN services are outside
the scope of this document. The framework document [L2VPN_FR] and
several documents, which explain technical approaches providing
L2VPN services, 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 [L2VPN_FR].
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 normal situation as
well as 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.
[Page 4]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
A proper design of L2VPNs aids formulation of SLSs in that it
provides means for proper separation between CE and PE, allows
proper execution of the SLS offer, and supports 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 a SP. These
requirements provide high-level L2VPN features expected by a SP in
provisioning L2VPNs, which include SP requirements for security,
privacy, manageability, interoperability and scalability.
2.2 Outline
The outline of the rest of this document is as follows. Section 3
provides definitions and taxonomy. Section 4 provides common
requirements that apply to both customer and SP respectively.
Section 5 states requirements from a customer perspective. Section
6 states network requirements from a SP perspective. Section 7
states SP management requirements. Section 8 describes the
engineering requirements, particularly control and data plane
requirements. Section 9 provides security considerations. Section
10 lists acknowledgements. Section 11 provides a list of references
cited herein. Section 12 lists the editors' addresses.
3 Definitions and Taxonomy
3.1 Definitions
The terminology used in this document is defined in [VPN_TERM]. The
L2VPN framework document [L2VPN_FR] 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.
3.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 a L2VPN reference model.
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ........................ | +-----+
L2VPN A | +----+ +----+ | L2VPN A
+--| PE |--- Service ---| PE |--+
+----+ Provider +----+
/ . Backbone . \ - /\-_
+-----+ / . | . \ / \ / \ +-----+
+ CE4 +--+ . | . +--\ Access \----| CE5 |
+-----+ . +----+ . | Network | +-----+
L2VPN B .........| PE |......... \ / L2VPN B
+----+ ^ -------
| |
[Page 5]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
| |
+-----+ |
| CE3 | +-- Logical switching instance
+-----+
L2VPN A
Figure 1 L2VPN Reference Model
3.3 VPWS
The PE devices provide a logical interconnect such that a pair of CE
devices appear 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 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.
3.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 ([L2VPN_FR]). A VPLS can contain a single VLAN
or multiple VLANs ([IEEE_802.1Q]). A variation of this service is
IPLS ([L2VPN_FR]), 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. The CE sees
a bridge.
The details of VPLS reference model, which we summarize here, can be
found in [L2VPN_FR]. 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 [L2VPN_FR].
Hence, the VSI terminates PWs for interconnection with other VSIs
and also terminates attachment circuits (ACs) for accommodating CEs.
A VSI includes the forwarding information base for a L2VPN
[L2VPN_FR] which is the set of information regarding how to forward
[Page 6]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
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
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.
4 Service Requirements Common to Customers and Service Providers
This section contains requirements that apply to both the customer
and the provider, or are of an otherwise general nature.
4.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 BPDU frames are sent as data
packets, then BPDU frames can be duplicated or mis-sequenced.
- 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 ([L2VPN_FR]) 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 MAY NOT be preserved by
the IPLS solution.
4.2 Traffic Types
A VPLS MUST support unicast, multicast, and broadcast traffic.
Support for efficient replication of broadcast and multicast traffic
is highly desirable.
4.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:
[Page 7]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
o Point-to-point
o Point-to-multipoint, a.k.a. hub and spoke
o Any-to-any, a.k.a. full mesh
o Mixed, a.k.a. partial mesh
o 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 implemented with point to point circuits. This requirement
does not imply that all traffic characteristics (such as bandwidth,
QoS, delay, etc.) be necessarily the same between any two end points
of a 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, a L2VPN service SHOULD be capable of
crossing multiple administrative boundaries.
To the extent possible, the L2VPN services SHOULD be independent of
access network technology.
4.4 Isolated Exchange of Data and Forwarding Information
L2VPN solutions SHALL define means that prevent CEs in a 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 a L2VPN SHOULD not be advertised nor
discoverable from outside that L2VPN.
4.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 a
L2VPN, ranging from mis-configurations to attacks that can be
launched on a L2VPN. This section lists some potential security
hazards. There MUST be methods available to protect against the
following situations.
- Protocol attacks
o Excessive protocol adjacency setup/teardown
[Page 8]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
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
4.5.1 User data security
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.
4.5.2 Access control
A L2VPN solution MAY also have the ability to activate the
appropriate filtering capabilities upon request of a customer.
4.6 Addressing
A L2VPN solution MUST support overlapping addresses of different
L2VPNs. For instance, customers SHOULD not be prevented from using
the same MAC addresses and/or the same VLAN Ids when used with
different L2VPNs. Actually, for VLANs, there are two cases. First,
a L2VPN is oblivious to customer VLANs. In this case, customers can
have overlapping VLAN Ids. Second, VLAN Ids MAY be used as service
delimiters, in which case it depends on whether the SP assigns the
VLANs or not. If it does, then there is no overlapping. If it
doesn't, then overlapping VLAN Ids can occur and the SP has to put
safeguards in place to avoid this situation.
[Page 9]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
4.7 Quality of Service
To the extent possible, L2VPN QoS SHOULD be independent of the
access network technology.
4.7.1 QoS Standards
As provided in [PPVPN_REQTS] a L2PVN 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.
4.7.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 an edge-to-edge QoS service. The details of the service
models can be found in [PPVPN_REQTS] and in [L3VPN_REQTS]. In L2VPN
service, both DSCP ([RFC2474]) and 802.1p ([IEEE_802.1D]) fields MAY
be used for this purpose.
4.8 Service Level Specifications
For a L2VPN service, the capabilities for Service Level
Specification (SLS) monitoring and reporting stated in [PPVPN_REQTS]
SHOULD be provided.
4.9 Protection and Restoration
The L2VPN service infrastructure SHOULD provide redundant paths to
assure 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 detect a failure in the L2VPN.
4.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),
[Page 10]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
- logical links (e.g., ATM PVC, and RFC2427-encapsulated link),
- transport networks carrying Ethernet,
- a Layer-2 tunnel that go 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.).
4.11 Management
Standard interfaces to manage L2VPN services MUST be provided
(e.g., standard SNMP MIBs). 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, Provisioning, and
Security, as detailed in [L3VPN_REQTS].
4.12 Interoperability
Multi-vendor interoperability at network element, network and
service levels among different implementations of the same technical
solution SHOULD be guaranteed (that will likely rely on the
completeness of the corresponding standard). This is a central
requirement for SPs and customers.
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 usage of the L2VPN service.
A L2VPN solution SHOULD NOT preclude different access technologies.
For instance, customer access connections to a L2VPN service MAY be
different at different CE devices (e.g., Frame Relay, ATM, 802.1d,
MPLS).
4.13 Inter-working
Inter-working scenarios among different solutions, providing L2VPN
services, are highly desirable. 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.
5 Customer Requirements
This section captures requirements from a customer perspective.
5.1 Service Provider Independence
Customers MAY require L2VPN service that spans multiple
administrative domains or SP networks. Therefore, a L2VPN service
[Page 11]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
MUST be able to span multiple AS and SP networks, but still to act
and to appear as a single, homogenous L2VPN from a customer point of
view.
A customer might also start with a L2VPN provided in a single AS
with a certain SLS but then ask for an expansion of the service
spanning multiple ASs 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.
5.2 Layer-3 Support
With the exception of IPLS, a 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.
5.3 Quality of Service and Traffic Parameters
QoS is expected to be an important aspect of a 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 and interactive video, and
multimedia applications. Hence, best-effort as well as delay and
loss sensitive traffic MUST be supported over a L2VPN service.
A customer application SHOULD experience consistent QoS independent
of the access network technology used at different sites connected
to the same L2VPN.
5.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 MIBs).
5.5 Security
5.5.1 Isolation
A 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.
[Page 12]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
A L2VPN service MAY use customer VLAN Ids as service delimiters. In
that case, they MUST be honored and traffic separation MUST be
provided.
5.5.2 Access control
A 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.
5.5.3 Value added security services
A L2VPN solution MAY provide value added security services such as
encryption and/or authentication of customer packets, certificate
management, and similar.
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]), MAY inhibit
L2VPN services, when the service delimiting VLAN Ids are encrypted.
5.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.
5.6.1 Physical/Link Layer Technology
L2VPNs 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.
5.6.2 Access Connectivity
Various types of physical connectivity scenarios MUST be supported,
such as multi-homed sites, backdoor links between customer sites,
devices homed to two or more SP networks. In case of VPLS, multi-
link access for CE devices SHOULD be supported. L2VPN solutions
SHOULD support at least the types of physical or link-layer
connectivity arrangements shown in Figure 2-Figure 4 (in addition to
the case shown in Figure 1). As in Figure 2, a CE can be dual-homed
to a SP or to two different SPs via diverse access networks.
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
[Page 13]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
| +------+ | +------+
| | 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
+------+ +------+ +------+ +------+
| |
[Page 14]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
+---------------- +---------------
(a) (b)
Figure 4 Combination of Dual-Homing and Backdoor Links for CE Devices
5.7 Customer traffic
5.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.
5.7.2 Packet Re-ordering
The queuing and forwarding policies SHOULD preserve packet order for
packets with the same QoS parameters.
5.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 fragment packets as long as it is transparent to the
customer.
5.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.
5.7.5 Transparency
The L2VPN service is intended to be transparent to Layer-2 customer
networks. A 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 which are
transported by the IPLS. However, the IPLS solution is NOT REQUIRED
to preserve the Layer-2 header transparently from CE to CE. For
[Page 15]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
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.
5.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 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.
5.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.
6 Service Provider Network Requirements
This section describes requirements from a SP perspective.
6.1 Scalability
This section contains projections regarding L2VPN sizing and
scalability requirements and metrics specific to particular
solutions.
6.1.1 Service Provider Capacity Sizing Projections
This section captures projections for scaling requirements over the
next several years in terms of number of L2VPNs, number of
interfaces per L2VPN, the size of forwarding information base per
L2VPN, and the rate of L2VPN configuration changes. The examples
are provided in [PPVPN_REQTS].
The numbers provided in this section are examples and MUST be
treated as such. A L2VPN solution MAY scale much more than the
examples provided here. Each requirement in this section MUST be
considered independently.
A L2VPN solution SHOULD be scalable to support a very large number
of L2VPNs per SP network. The estimate is that a large SP will
require support of O(10^5) VPWSs and O(10^4) VPLSs within the next
four years.
A L2VPN solution SHOULD be scalable to support of a wide range of
number of site interfaces per VPLS, depending on the size and/or
structure of the customer organization. The number of site
interfaces SHOULD range from a few site interfaces to O(10^2) site
interfaces per VPLS.
[Page 16]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
A L2VPN solution SHOULD be scalable to support a wide range of
number of customer addresses (e.g., MAC) per VPLS. The number of
customer addresses per VPLS MAY range from just a few (i.e., the
number of sites when the CE devices are routers or when the service
is IPLS) to a very large number such as 1,000 (i.e., when CE devices
are switches). The number of customer addresses would be on the
order of addresses supported in a typical native Layer-2 backbone.
A L2VPN solution SHOULD support high values of the frequency of
configuration setup and change, e.g., for real-time provisioning of
an on-demand videoconferencing or addition/deletion of sites.
Approaches SHOULD articulate scaling and performance limits for more
complex deployment scenarios, such as inter-AS(S) L2VPNs and
carriers' carrier. Approaches SHOULD also describe other dimensions
of interest, such as capacity requirements or limits, number of
inter-working instances supported as well as any scalability
implications on management systems.
The number of users per VPLS is the combination of servers and hosts
connected to the VPLS. It needs to scale from a handful to high
numbers. A VPLS MUST scale from 2 users to a few hundred.
The number of users per VPLS interface follows the same logic as for
users per VPLS. Further, it MUST be possible to have single user
sites connected to the same VPLS as very large sites are connected
to. VPLSs MUST scale from 1 user to a few hundred per site.
The number of sites per VPLS is clearly limited by the number of
users for a VPLS. The largest number of sites in a VPLS would be
equal to the largest number of users, distributed one per site.
The number of L2VPNs SHOULD scale linearly with the size of the
access network and with the number of PEs.
6.1.2 Solution-Specific Metrics
Each L2VPN solution SHALL document its scalability characteristics
in quantitative terms.
6.2 Identifiers
A SP domain MUST be uniquely identified at least within the set of
all interconnected SP networks when supporting a 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 a
L2VPN spans multiple SPs (e.g., [RFC2685]). Globally unique
identifiers facilitate the support of inter-AS/SP L2VPNs.
[Page 17]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
6.3 Discovering L2VPN Related Information
Configuration of PE devices (i.e., U-PE and N-PE [L2VPN_FR]) is a
significant task for a SP. Solutions SHOULD provide methods that
dynamically allow L2VPN information to be discovered by the PEs to
minimize the configuration steps.
Each device in a L2VPN SHOULD be able to determine which other
devices belong to the same L2VPN. Such a membership discovery
scheme MUST prevent unauthorized access and allows authentication of
the source.
Distribution of L2VPN information SHOULD be limited to those devices
involved in that L2VPN. A L2VPN solution SHOULD employ discovery
mechanisms to minimize the amount of operational information
maintained by the SPs. For example, if a SP adds or removes a
customer port on a given PE, the remaining PEs SHOULD determine the
necessary actions to take without the SP having to explicitly
reconfigure those PEs.
A L2VPN solution SHOULD support the means for attached CEs to
authenticate each other and verify that the SP L2VPN is correctly
configured.
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 a L2VPN solution.
6.4 SLS Support
Typically, a SP offering a L2VPN service commits to specific SLS as
part of a contract with the customer. Such a SLA drives the
specific SP requirements for measuring specific SLSs for quality,
availability, response time, and configuration intervals.
6.5 Quality of Service (QoS)
A significant aspect of a provider provisioned VPN is support for
QoS. A 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 [L3VPN_REQTS].
6.6 Isolation of Traffic and Forwarding Information
From a high level SP perspective, a L2VPN MUST isolate the exchange
of traffic and forwarding information to only those sites that are
authenticated and authorized members of a L2VPN.
[Page 18]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
A 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.
6.7 Security
The security requirements are stated in Section 4.5. The security
requirements provided in [PPVPN_REQTS] SHOULD be met. The security
requirements, except Layer-3 and higher layer dependent ones,
specified in [L3VPN_REQTS] SHOULD be met.
In addition, a SP network MUST be immune to malformed or maliciously
constructed customer traffic. This includes but 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.
6.8 Inter-AS/SP L2VPNs
All applicable SP requirements, such as traffic and forwarding
information isolation, SLS's, management, security, provisioning,
etc. MUST be preserved across adjacent AS's. The solution MUST
describe the inter-SP network interface, encapsulation method(s),
routing protocol(s), and all applicable parameters.
A L2VPN solution MUST provide the specifics of offering L2VPN
services spanning multiple ASs and/or SPs.
A L2VPN solution MUST support proper dissemination of operational
parameters to all elements of a L2VPN service in the presence of
multiple ASs and/or SPs. A L2VPN solution MUST employ mechanisms
for sharing operational parameters between different ASs
A L2VPN solution SHOULD support policies for proper selection of
operational parameters coming from different ASs. Similarly, a
L2VPN solution SHOULD support policies for selecting information to
be disseminated to different ASs.
6.8.1 Management
The general requirements for managing a single AS apply to a
concatenation of AS's. A minimum subset of such capabilities is the
following:
- Diagnostic tools
- Secured access to one AS management system by another
[Page 19]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
- Configuration request and status query tools
- Fault notification and trouble tracking tools
6.8.2 Bandwidth and QoS Brokering
When a L2VPN spans multiple AS's, 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 AS's can
establish and guarantee uniform QoS in support of a provider
provisioned VPN.
6.9 L2VPN Wholesale
The architecture MUST support the possibility of one SP offering
L2VPN service to another SP. One example is when one SP sells L2VPN
service at wholesale to another SP, who then resells that L2VPN
service to his or her customers.
6.10 Tunneling Requirements
Connectivity between CE sites or PE devices in the backbone SHOULD
be able to use a range of tunneling technologies, such as L2TP, GRE,
IP-in-IP, MPLS, etc.
Every PE MUST support a tunnel setup protocol, if tunneling is used.
A PE MAY support static configuration. If employed, a tunnel
establishment protocol SHOULD be capable of conveying information,
such as the following:
- Relevant identifiers
- QoS/SLS 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 SP and its associated
mechanisms for tunnel establishment, multiplexing, and maintenance
MUST meet the requirements on scaling, isolation, security, QoS,
manageability, etc.
Regardless of the tunneling choice, the existence of the tunnels and
their operations MUST be transparent to the customers.
6.11 Support for Access Technologies
The connectivity between PE and CE devices is referred to as an AC.
ACs MAY span networks of other providers or public networks.
[Page 20]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
There are several choices for implementing ACs. Some popular
choices include Ethernet, ATM (DSL), Frame Relay, MPLS-based virtual
circuits etc.
In case of VPLS, the AC MUST use Ethernet frames as the Service
Protocol Data Unit (SPDU).
A CE access connection over an AC MUST be bi-directional.
PE devices MAY support multiple ACs on a single physical interface.
In such cases, PE devices MUST NOT rely on customer controlled
parameters for distinguishing between different access connections.
For example, if VLAN tags were used for that purpose, the provider
would be controlling the assignment of the VLAN tag values and would
strictly enforce compliance by the CEs.
An AC, whether direct or virtual, MUST maintain all committed
characteristics of the customer traffic, such as QoS, priorities
etc. The characteristics of an AC are only applicable to that
connection.
6.12 Backbone Networks
Ideally, the backbone, interconnecting SP's 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 SLSs for VPN service
offerings.
6.13 Network Resource Partitioning and Sharing Between L2VPNs
In case network resources such as memory space, forwarding
information base table, bandwidth and CPU processing are shared
between L2VPNs, the solution SHOULD guarantee availability of
resources necessary to prevent any specific L2VPN service instance
from taking up available network resources and causing others to
fail. The solution SHOULD be able to limit the resources consumed
by a L2VPN service instance. The solution SHOULD guarantee
availability of resources necessary to fulfill the obligation of
committed SLSs.
6.14 Interoperability
Service providers are interested in interoperability in at least the
following scenarios:
- To facilitate use of PE and managed CE devices within a single
SP network
- To implement L2VPN services across two or more interconnected
SP networks
- To achieve inter-working or interconnection between customer
sites using different L2VPN solutions or different
implementations of the same approach
[Page 21]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
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.
6.15 Testing
The L2VPN solution SHOULD provide the ability to test and verify
operational and maintenance activities on a per L2VPN service basis,
and in case of VPLS, on a per VLAN basis if customer VLANs are used
as service delimiters.
The L2VPN solution SHOULD provide mechanisms for connectivity
verification, and for detecting and locating faults.
Examples of testing mechanisms are as follows:
- Checking connectivity between "service-aware" network nodes
- Verifying data plane and control plane integrity
- Verifying service membership
The provided mechanisms MUST satisfy the following: the
connectivity checking for a given customer MUST enable the end-to-
end testing of the data path used by that of customer's data packets
and the test packets MUST not propagate beyond the boundary of the
SP network.
6.16 Support on Existing PEs
To the extent possible, the IPLS solution SHOULD facilitate support
of IPLS on existing PE devices that may be already deployed by the
SP and MAY have been designed primarily for Layer-3 services.
7 Service Provider Management Requirements
A SP desires to have a means to view the topology, operational
state, and other parameters associated with each customer's L2VPN.
Furthermore, the SP requires a means to view the underlying logical
and physical topology, operational state, provisioning status, and
other parameters associated with the equipment providing the L2VPN
service(s) to its customers. Therefore, the devices SHOULD provide
standards-based interfaces (e.g., L2VPN MIBs) wherever feasible.
The details of service provider management requirements for a
Network Management System (NMS) in the traditional fault,
configuration, accounting, performance, and security (FCAPS)
management categories can be found in [ITU_Y.1311.1].
8 Engineering Requirements
These requirements are driven by implementation characteristics that
make service and SP requirements achievable.
8.1 Control Plane Requirements
A L2VPN service SHOULD be provisioned with minimum number of steps.
Therefore, the control protocols SHOULD provide methods for
[Page 22]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
signaling between PEs. The signaling SHOULD inform of membership,
tunneling information, and other relevant parameters.
The infrastructure MAY employ manual configuration methods to
provide this type of information.
The infrastructure SHOULD use policies to scope the membership and
reachability advertisements for a particular L2VPN service. A
mechanism for isolating the distribution of reachability information
to only those sites associated with a L2VPN MUST be provided.
The control plane traffic increases with the growth of L2VPN
membership. Similarly, the control plane traffic increases with the
number of supported L2VPN services. The use of control plane
resources MAY increase as the number of hosts connected to a L2VPN
service grows.
A L2VPN solution SHOULD minimize control plane traffic and the
consumption of control plane resources. The control plane MAY offer
means for enforcing a limit on the number of customer hosts attached
to a L2VPN service.
8.2 Data Plane Requirements
8.2.1 Encapsulation
A L2VPN solution SHOULD utilize the encapsulation techniques defined
by PWE3 ([PWE3_ARCH]), and SHOULD not impose any new requirements on
these techniques.
8.2.2 Responsiveness to Congestion
A L2VPN solution SHOULD utilize the congestion avoidance techniques
defined by PWE3 ([PWE3_ARCH]).
8.2.3 Broadcast Domain
A separate Broadcast Domain MUST be maintained for each VPLS.
In addition to VPLS Broadcast Domains, a L2VPN service MAY honor
customer VLAN Broadcast Domains, if customer VLANs are used as
service delimiters. In that case, the L2VPN solution SHOULD
maintain a separate VLAN Broadcast Domain for each customer VLAN.
8.2.4 Virtual Switching Instance
L2VPN PE devices MUST maintain a separate VSI per VPLS. Each VSI
MUST have capabilities to forward traffic based on customer's
traffic parameters such as MAC addresses, VLAN tags (if supported),
etc. as well as local policies.
L2VPN PE devices MUST have capabilities to classify incoming
customer traffic into the appropriate VSI.
Each VSI MUST have flooding capabilities for its Broadcast Domain to
facilitate proper forwarding of Broadcast, Multicast and Unknown
Unicast customer traffic.
[Page 23]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
8.2.5 MAC address learning
A VPLS SHOULD derive all topology and forwarding information from
packets originating at customer sites. Typically, MAC address
learning mechanisms are used for this purpose. With IPLS, snooping
of particular packets originating at customer sites and signaling
might also be used.
Dynamic population of the forwarding information base (e.g., via MAC
address learning) MUST take place on a per VSI basis, i.e., in the
context of a VPLS and, if supported, in the context of VLANs
therein.
9 Security Considerations
Security considerations occur at several levels and dimensions
within L2VPNs, as detailed within this document.
The requirements based on security concerns and potential security
hazards are detailed in section 4.5.. Further details on security
requirements are given from the customer and service provider
perspectives in sections 5.5 and 6.7, respectively. In an analogous
manner, further detail on traffic and routing isolation requirements
are given from the customer and service provider perspectives in
sections 4.4 and 6.6, respectively. Safeguards to protect network
resources such as CPU, memory, and bandwidth are required in section
6.13.
IPSec can also be applied after tunneling Layer-2 traffic to provide
additional security.
10 Acknowledgments
The authors would like to acknowledge extensive comments and
contributions provided by Loa Andersson, Joel Halpern, Eric Rosen,
Ali Sajassi, Muneyoshi Suzuki, Ananth Nagarajan, Dinesh Mohan, Yakov
Rekhter, Matt Squire, Norm Finn, Scott Bradner, and Francois Le
Faucheur. The authors, also, wish to extend their appreciation's to
their respective employers and various other people who volunteered
to review this work and provided feedback. This work was done in
consultation with the entire Layer-2 PPVPN design team. A lot of
the text was adapted from the Layer-3 VPN requirements document
produced by Layer-3 VPN requirements design team.
11 References
11.1 Normative References
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[VPN_TERM] Andersson, L, Madsen, T. "PPVPN Terminology", work
in progress
[Page 24]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
11.2 Informative References
[L2VPN_FR] Andersson, L, et al. "L2VPN Framework", work in
progress
[IEEE_802.1Q] IEEE Std 802.1Q-1998, "Virtual Bridged Local Area
Networks", 1998
[PPVPN_REQTS] Nagarajan, A., et al. "Generic Requirements for
Provider Provisioned VPN", work in progress
[RFC3270] Le Faucheur, F., et al. "Multi-Protocol Label
Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[RFC3308] Calhoun, P., et al, "Layer 2 Tunneling Protocol
(L2TP) Differentiated Services Extension", RFC
3308, November 2002.
[RFC2205] Braden, R., et al, "Resource ReSerVation Protocol
(RSVP)", RFC 2205, September 1997.
[L3VPN_REQTS] Carugi, M., McDysan, D. et. al., "Service
Requirements for Layer 3 Provider Provisioned
Virtual Private Networks", work in progress
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[IEEE_802.1D] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998
Edition (Revision and redesignation of ISO/IEC
10038:98), "Part 3: Media Access Control (MAC)
Bridges", 1998.
[IEEE_802.10] IEEE Std 802.10-1998 Edition (Revision IEEE Std
802.10-1992, incorporating IEEE Std 802.10b-1992,
802.10e-1993, 802.10f-1993, 802.10g-1995, and
802.10h-1997), "Standard for Interoperable LAN/MAN
Security (SILS)", 1998.
[IEEE_802.1s] IEEE Std 802.1s-2002, "Virtual Bridged Local Area
Networks- Amendment 3: Multiple Spanning Trees",
2002.
[RFC2685] Fox B., et al, "Virtual Private Networks
Identifier", RFC 2685, September 1999.
[ITU_Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over
MPLS architecture",Y.1311.1 ITU-T Recommendation,
May 2001
[PWE3_ARCH] Bryant, S. "PWE3 Architecture", work in progress
12 Editors' Addresses
Waldemar Augustyn
Email: waldemar@nxp.com
Yetik Serbest
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
Email: yetik_serbest@labs.sbc.com
[Page 25]
Internet Draft draft-ietf-l2vpn-requirements-01.txt February, 2004
Full copyright statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
[Page 26]