PPVPN Working Group Waldemar Augustyn Internet Draft Yetik Serbest Document: draft-augustyn-ppvpn-l2vpn-requirements-01.txt (Editors) Category: Informational October 2002 Expires: April 2003 Requirements for Layer 2 Virtual Private Network Services (L2VPN) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1 Abstract This draft describes service requirements for Provider Provisioned L2 Virtual Private Networks. It covers point to point VPNs referred to as Virtual Private Wire Service (VPWS), as well as broadcast domain multipoint to multipoint VPNs referred to as Virtual Private LAN Service (VPLS). L2VPNs are a class of Provider Provisioned Virtual Private Network [2]. This draft is intended to supersede draft-ietf-ppvpn-vpls- requirements-01.txt [3]. Augustyn, et. al. Expires April 2003 1 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 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 [4]. 3 Contributing Authors This document was the combined effort of several individuals that were part of the PPVPN requirements design team. The following are the authors that contributed to this document: Waldemar Augustyn 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 [5]. Some additional definitions related to L2VPN services are provided below. L2VPN System: A collection of communication equipment, related protocols, and configuration elements that implements L2VPN Services. VPLS Domain: A Layer 2 VPN that is composed of a community of interest of L2 MAC addresses and VLANs. Each VPLS Domain MAY have multiple VLANs in it. VLAN Flooding Scope (VLAN Broadcast Domain): The scope of flooding for a given VLAN. In a VPLS service, a VLAN flooding scope is identical to the flooding scope of the VPLS it is part of. If a VPLS service is extended to recognize customer VLANs, the VLAN flooding scope is limited to the broadcast domain of each recognized VLAN. 4.2 Taxonomy The requirements distinguish two major L2VPNs models, a Virtual Private Wire Service (VPWS), and a Virtual Private LAN Service (VPLS). The VPWS model is simpler than VPLS and its requirements are a subset of those for VPLS. Augustyn, et al. Expires April 2003 2 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 The document generally refers to L2VPN requirements which are applicable to both VPWS and VPLS. The additional requirements for VPLS are clearly stated as such. The IPLS model can be considered a subset of VPLS. The specific requirements for this service, that differ from the VPLS case, are under study. Virtual Private Wire Service: By far the most widely deployed are point to point VPNs. A point to point VPN behaves like a circuit terminated by a Customer Equipment (CE) at each end. This type of L2VPN service is referred to as Virtual Private Wire Service, VPWS. A variation of that service, point to multipoint non-broadcast L2VPN, differs only slightly from the point to point VPN by offering more than one end point. The behavior of that VPN, however, remains point to point by nature. No replication is supported. The requirements for VPWS fully apply. Virtual Private LAN Service: The VPLS service emulates a LAN segment for the members of the VPN. The VPLS provides the capability to replicate packets, to operate loop-free, and to interpret broadcast and multicast addresses according to their meaning. A variation of this service is IPLS, which is limited to supporting only IP traffic. 5 Introduction This document describes the service requirements for Layer 2 Virtual Private Networks. The framework for services is described in [6]. 5.1 The context of provider provisioned service The context of provider provisioned VPNs is an important factor in the structure and scope of the requirements. This context brings attention to the fact that 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 Agreement (SLA). A proper design of L2 VPNs aids formulation of SLAs in that it provides means for proper separation between CE/PE, allows proper execution of the SLA offer, and supports flexible and rich set of capabilities. 6 L2VPN Reference Model Augustyn, et al. Expires April 2003 3 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 The following diagram shows a L2VPN reference model where PE devices provide a logical interconnect such that CE devices belonging to a specific L2VPN appear to be connected by a single logical switching instance. +-----+ +-----+ + 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 6.1 VPWS The PE devices provide a logical interconnect such that a pair of CE devices appear to be connected by a single logical L2 circuit. PE devices maintain separate L2VPN domains for each logical L2 circuit. Such domains are then mapped onto tunnels in the service provider network. These tunnels can either be specific to a particular L2VPN, or shared among several L2VPNs (e.g. as with MPLS tunnel LSPs). In the above diagram, L2VPN B represents a VPWS case. The CE-to-PE links can either be direct physical links, e.g. 100BaseTX, T1/E1 TDM, or logical links, e.g. ATM PVC, or RFC2427- encapsulated link, over which L2 traffic is carried. The L2VPN transport supports homogeneous interfaces such as Ethernet-to- Ethernet or ATM-to-ATM (e.g., like-to-like services). It can, optionally, support heterogeneous interfaces such as ATM-to-FR or ATM-to-Ethernet (also known as any-to-any services) with proper interworking functions. The PE-to-PE links carry tunneled L2 frames using different tunneling technologies (e.g., IP-in-IP, GRE, IPSec, MPLS, L2TP, etc.). Augustyn, et al. Expires April 2003 4 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 Each PE device is responsible for allocating customer L2 frames to the appropriate VPWS and for proper forwarding to the intended end nodes. The VPWS is basically a set of point to point virtual circuits over an IP or MPLS network among the CEs. It consists of Attachment and Emulated VCs. The virtual circuit between a CE device and a PE device is called the "Attachment VC" and the virtual circuit between the two PEs, that is used to provide a layer 2 connection between the two CEs, is called "Emulated VC". At each PE, the Emulated VC is associated with an Attachment VC and the ordered triplet functions as a VC between the two CEs. 6.2 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 emulated LAN. A VPLS can contain a single VLAN or multiple, tagged VLANs. Separate L2 broadcast domains are maintained on a per VPLS basis by PE devices. Such domains are then mapped onto tunnels in the service provider network. These tunnels can either be specific to a VPLS (e.g. as with IP) or shared among several VPLSs (e.g. as with MPLS tunnel LSPs). In the above diagram, the top PE routers maintain separate forwarding instances for VPLS A and VPLS B. The CE-to-PE links can either be direct physical links, e.g. 100BaseTX, T1/E1 TDM or logical links, e.g. ATM PVC, or RFC2427- encapsulated link, over which emulated LAN traffic is carried. The PE-to-PE links carry tunneled Ethernet frames using different tunneling technologies (e.g., IP-in-IP, GRE, IPSec, MPLS, L2TP, etc.). Each PE device learns remote MAC addresses, and is responsible for proper forwarding of the customer traffic to the appropriate end nodes. It is responsible for guaranteeing each VPLS topology is loop free. 7 Generic Requirements A L2VPN solution SHOULD meet the requirements stated in [7] as appropriate. Augustyn, et al. Expires April 2003 5 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 8 L2VPN General Service Requirements 8.1 Scope of emulation The L2VPN solutions MUST be limited to emulating known, native WAN, LAN, or Bridge network services and protocols. The interaction between L2VPN and the customer equipment SHOULD comply with existing native protocols and specifications. In case, a L2VPN solution supports only a subset of these specifications, the exceptions MUST be documented. 8.2 Layer 2 Domain Representation A L2VPN system MUST distinguish different customer domains. Each of these customer domains MUST appear as a L2 VPN. For the customer devices, the L2VPN domain SHOULD behave like a native L2 network implied by the selected L2 protocol. For example, if a CE connects to a L2VPN via a FR circuit, it should expect the behavior of the VPN be similar to a connection to a true FR switch. A L2VPN MAY span multiple service providers A provider's implementation of a L2VPN system SHOULD NOT constrain the customer's ability to configure VPN topologies, customer network topologies, or Layer 2 parameters related to the supported L2 protocol. For example, the system must be prepared to deal with back-door links, accept full range of VLAN tags, etc. In case of VPLS, each domain MUST be capable of learning and forwarding based on MAC addresses thus emulating a LAN to the customer CE devices attached to PEs. A VPLS system MAY recognize customer VLAN identification. In that case, a VLAN MUST be recognized in the context of the VPLS it is part of. If customer VLANs are recognized, separate VLAN broadcast domains SHOULD be maintained. 8.3 L2VPN Topology The L2VPN system 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: 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 Augustyn, et al. Expires April 2003 6 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 Regardless of the topology employed, the service to the customers MUST retain the connectivity type implied by the type of L2VPN. For example, a VPLS should 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. 8.4 Addressing Each L2VPN service MUST be identified by a unique VPN-ID. The VPN- ID SHOULD be a globally unique value which can feasibly be administered in a multi-provider space. A L2VPN solution MUST support overlapping addresses of different L2VPN services. For instance, customers should not be prevented from using the same MAC addresses and/or the same VLAN Ids when used with different instances of L2VPN service. 8.5 Redundancy and Failure Recovery The L2VPN 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. It is RECOMMENDED that the restoration time be less than the time it takes the CE devices, or customer L2 control protocols, as well as L3 routing protocols, to detect a failure in the L2VPN. In cases where the provider knows a priori about impending changes in network topology, the network SHOULD have the capability to reconfigure without a loss, duplication, or re-ordering of customer packets. This situation typically arises with planned network upgrades or scheduled maintenance activities. 8.6 Policy Constraints A L2VPN system MAY employ policy constraints governing various interconnection attributes for L2VPN domains. Typical attributes include: o Selection of available network infrastructure o QoS services needed o Protection services needed o Availability of higher level service access points (see 11.7 ) Augustyn, et al. Expires April 2003 7 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 Policy attributes SHOULD be advertised via the L2VPN system's control plane. 8.7 PE nodes The PE nodes are the devices in the L2VPN system that store information related to customer L2VPN domains and employ methods to forward customer traffic based on that information. In this document, the PE nodes are meant in logical sense. In the actual implementations, the PE nodes MAY be comprised of several physical devices. For instance, MAC learning can be performed in one, and layer-3 routing and MPLS LSP tunnel establishment can be done in another. Conversely, a single physical device MAY contain more than one PE node. All forwarding decisions related to customer L2VPN traffic MUST be made by PE nodes. This requirement prohibits any other network components from altering decisions made by PE nodes. 8.8 PE-PE Interconnection and Tunneling A L2VPN system MUST provide connectivity between each pair of PE nodes. The connectivity is referred to as transport tunneling or simply tunneling. There are several choices for implementing transport tunnels. Some popular choices include IP in IP tunnels, GRE, MPLS, and variations of 802.1Q, etc. Regardless of the choice, the existence of the tunnels and their operations MUST be transparent to the customers. 8.9 PE-CE Interconnection and Profiles A L2VPN system MUST provide connectivity between PE nodes and CE nodes. That connectivity is referred to as an Attachment Circuit (AC). Attachment Circuits MAY span networks of other providers or public networks. 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 Attachment Circuit MUST use Ethernet frames as the Service Protocol Data Unit (SPDU). A CE access connection over an AC MUST be bi-directional in nature. 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. Augustyn, et al. Expires April 2003 8 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 For example, if VLAN tags were used for that purpose, the provider would be controlling the assignment of the tag values and would strictly enforce compliance by the CEs. An AC connection, whether direct or virtual, MUST maintain all committed characteristics of the customer traffic, such as QoS, priorities etc. The characteristics of an AC connection are only applicable to that connection. 9 Control Plane Requirements 9.1 Provider Edge Signaling A L2VPN SHOULD be provisioned with minimum number of steps. Therefore, the control protocols SHOULD provide methods for 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. 9.2 L2VPN Membership Discovery The control plane and/or the management plane SHOULD provide methods to discover (i.e., auto-discovery) the PEs which connect CEs forming a L2VPN. 9.3 Support for Layer 2 control protocols The L2VPN system's control protocols SHOULD allow transparent operation of Layer 2 control protocols employed by customers. In case of VPLS, the VPLS system MUST ensure that loops be prevented. This can be accomplished through a loop free topologies or appropriate forwarding rules. Control protocols such as Spanning Tree (STP) or similar could be employed. The system's control protocols MAY use indications from customer control protocols, e.g. STP, to improve the operation of a VPLS. 9.4 Scaling Requirements In a L2VPN system, the control plane traffic increases with the growth of L2VPN membership. Similarly, the control plane traffic Augustyn, et al. Expires April 2003 9 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 increases with the number of supported L2VPN domains. The rate of growth of the associated control plane traffic SHOULD be linear. The use of control plane resources increases as the number of hosts connected to a L2VPN grows. The rate of growth of the demand for control process resources SHOULD be linear. The control plane MAY offer means for enforcing a limit on the number of customer hosts attached to a L2VPN. Scalability examples for L2VPN services can be found in [7]. 10 Data Plane Requirements 10.1 Transparency L2VPN service is intended to be transparent to Layer 2 customer networks. It SHOULD NOT require any special packet processing by the end users before sending packets to the provider's network. 10.2 Additional requirements for VPWS systems 10.2.1 QoS A VPWS system MUST have capabilities to enforce QoS parameters. 10.2.2 Packet Re-ordering The queuing and forwarding policies MUST preserve packet order for packets with the same QoS parameters. The service MUST NOT duplicate packets. 10.3 Additional requirements for VPLS systems 10.3.1 QoS A VPLS system SHOULD have capabilities to enforce QoS parameters. 10.3.2 Packet Re-ordering The queuing and forwarding policies SHOULD preserve packet order for packets with the same QoS parameters. The service SHOULD not duplicate packets. Augustyn, et al. Expires April 2003 10 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 10.3.3 Broadcast Domain A separate Broadcast Domain MUST be maintained for each VPLS. In addition to VPLS Broadcast Domains, a VPLS system MAY recognize customer VLAN Broadcast Domains. In that case, the system SHOULD maintain a separate VLAN Broadcast Domain for each customer VLAN. A VLAN Broadcast Domain MUST be a subset of the owning VPLS Broadcast Domain. 10.3.4 Virtual Switching Instance VPLS Provider Edge devices MUST maintain a separate Virtual Switching Instance (VSI) per each VPN. 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. VPLS Provider Edge 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. 10.3.5 MAC address learning A VPLS service SHOULD derive all topology and forwarding information from packets originating at customer sites. Typically, MAC address learning mechanisms are used for this purpose. In a VPLS system, MAC address learning MUST take place on a per Virtual Switching Instance (VSI) basis, i.e. in the context of a VPLS and, if supported, in the context of VLANs therein. 10.3.6 Unicast, Unknown Unicast, Multicast, and Broadcast forwarding VPLS MUST be aware of the existence and the designated roles of special MAC addresses such as Multicast and Broadcast addresses. VPLS MUST forward these packets according to their intended functional meaning and scope. Broadcast packets MUST be flooded to all destinations. Multicast packets MUST be flooded to their intended destinations. A VPLS system MAY flood the multicast packets to all destinations if multicast snooping is not employed. Unicast packets MUST be forwarded to their intended destinations. Augustyn, et al. Expires April 2003 11 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 Unknown Unicast packets MUST be flooded to all destinations in the flooding scope of the VPLS (or VLAN). If the VPLS service relies on MAC learning for its operations, it MUST assure proper forwarding of packets with MAC addresses that have not been learned. Once destination MAC addresses are learned, unicast packets SHOULD be forwarded only to their intended destinations. A provider MAY employ a method to limit the scope of flooding of Unknown Unicast packets in cases where a customer desires to conserve its bandwidth or wants to implement certain security policies. 10.3.7 Minimum MTU The VPLS service MUST support customer frames with payload 1500 bytes long. The service MAY offer support for longer frames. The service MUST NOT fragment packets. Packets exceeding committed MTU size MUST be discarded. The committed minimum MTU size MUST be the same for a given instance of L2VPN. Different L2VPN instances MAY have different committed MTU sizes. If VLANs are supported, all VLANs within a given VPLS MUST inherit the same MTU size. 10.3.8 Multilink Access The VPLS service SHOULD support multilink access for CE devices. The VPLS service MAY support multi-home access for CE devices. 10.3.9 End-point VLAN tag translation If VLANs are recognized, the VPLS system MAY support translation of customers' VLAN tags. Such service simplifies connectivity of sites that want to keep their tag assignments or sites that belong to different administrative entities. In the latter case, the connectivity is sometimes referred to as L2 extranet. 10.3.10 Support for MAC Services VPLS are REQUIRED to provide MAC service compliant with IEEE 802.1D specification [8] Section 6. Compliance with this section facilitates proper operation of 802.1 LAN and seamless integration of VPLS with bridged Local Area Networks. It is also useful to compare [9], [10], and [11]. Augustyn, et al. Expires April 2003 12 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 A MAC service in the context of VPLS is defined as the transfer of user data between source and destination end stations via the service access points using the information specified in the VSI. 1. A PE device that provides VPLS MUST NOT be directly accessed by end stations except for explicit management purposes. 2. All MAC addresses MUST be unique within a given broadcast domain. 3. The topology and configuration of the VPLS MUST NOT restrict the MAC addresses of end stations 11 Management and Operations 11.1 L2VPN configuration and monitoring A L2VPN system MUST have capabilities to configure, manage, and monitor its different components. A L2VPN solution SHOULD provide mechanisms, such as authentication and authorization of CEs and sanity check of the L2VPN configuration, for proper and intended operation of the service. It SHOULD be possible to create several disjoint instances of L2VPN systems within the same underlying network infrastructures. The infrastructure SHOULD monitor all characteristics of the service that are reflected in the customer SLA. This includes but is not limited to bandwidth usage, packet counts, packet drops, service outages, etc. 11.2 L2VPN operations The operations of a L2VPN system is controlled by an Administrative Authority (Admin). The Admin is the originator of all operational parameters of a L2VPN system. Conversely, the admin is also the ultimate destination for the status of the L2VPN system and the related statistical information. A typical L2VPN system spans several such Admins. A L2VPN system MUST support proper dissemination of operational parameters to all elements of a L2VPN system in the presence of multiple Admins. A L2VPN system MUST employ mechanisms for sharing operational parameters between different Admins. These mechanisms MUST NOT assume any particular structure of the different Admins. For example the L2VPN should not be relying on Admins forming a hierarchy. Augustyn, et al. Expires April 2003 13 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 A L2VPN system SHOULD support policies for proper selection of operational parameters coming from different Admins. Similarly, a L2VPN system SHOULD support policies for selecting information to be disseminated to different Admins. A L2VPN system SHOULD employ discovery mechanisms to minimize the amount of operational information maintained by the Admins. For example, if an admin adds or removes a customer port on a given PE, the remaining PEs should determine the necessary actions to take without the Admins having to explicitly reconfigure those PEs. 11.3 CE Provisioning The L2VPN MUST require only minimal or no configuration on the CE devices, depending on the CE device that connects into the infrastructure. 11.4 Customer traffic policing The L2VPN service SHOULD provide the ability to police and/or shape customer traffic entering and leaving the L2VPN system. 11.5 Dynamic Service Signaling A Provider MAY offer to Customers an in-band method for selecting services from the list specified in the SLA. A Provider MAY use the same mechanism for reporting statistical data related to the service. 11.6 Class of Service Model The L2VPN service MAY define a graded selection of classes of traffic. These include, but are not limited to o Range of priorities o Best effort vs. guaranteed effort o Range of minimum delay characteristics 11.7 VPLS Access Option The VPLS solution SHOULD allow for a Provider based Service Access for orderly injection of L3 or higher services to the customers' VPLS segments. Augustyn, et al. Expires April 2003 14 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 In particular, the system SHOULD allow to build L3VPN services, including L3 interworking schemes such as ARP mediation or similar, over its L2VPNs. As a value added service, a Provider MAY offer access to other services such as, IP gateways, storage networks, content delivery etc. 11.8 Testing The L2VPN solution SHOULD provide the ability to test and verify operational and maintenance activities on a per L2VPN basis, and in case of VPLS, on a per VLAN basis. The L2VPN solution SHOULD provide mechanisms for connectivity verification, and for detecting/locating faults. Examples of testing mechanisms are as follows: o Checking connectivity between "service-aware" network nodes o Verifying data plane and control plane integrity o Verifying service membership The provided mechanisms MUST satisfy the following: the checking of connectivity MUST involve the ability to use packets that look like customer packets, and the testing packets MUST not propagate beyond the boundary of the provider network. 11.9 Network Resource Partitioning and Sharing Between L2VPNs In case network resources such as memory space, FIB table, bandwidth and CPU processing are shared between L2VPNs, the solution MUST guarantee availability of resources necessary to fulfill the obligation of committed SLAs. The solution MUST provide a deterministic method of calculating and enforcing the allocation of network resources necessary to support each instance of a L2VPN service. For example, any specific L2VPN must not take up more network resources than calculated a priori and causing other service instances to fail. 12 Security 12.1 Traffic separation L2VPN system MUST provide traffic separation between different L2VPN domains. Augustyn, et al. Expires April 2003 15 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 In case of VPLS, if VLANs are supported, the system MUST provide traffic separation between customer VLANs within each VPLS domain. 12.2 Provider network protection. The L2VPN system MUST be immune to malformed or maliciously constructed customer traffic. This includes but is not limited to duplicate or invalid L2 addresses, customer side loops, short/long packets, spoofed management packets, spoofed VLAN tags, high volume traffic, etc. The L2VPN infrastructure devices MUST NOT be accessible from the L2VPN. 12.3 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. 12.4 Value added security services Value added security services such as encryption and/or authentication of customer packets, certificate management, and similar are OPTIONAL. Security measures employed by the L2VPN system SHOULD NOT restrict implementation of customer based security add-ons. 13 Interoperability L2VPN solution SHOULD NOT preclude different access technologies. For instance, customer access connections to a L2VPN solution may be different at different CEs (e.g., Frame Relay, ATM, 802.1d, MPLS). 14 References 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2. Carugi, et al., "Service requirements for Provider Provisioned Virtual Private Networks ", Work in progress, December 2001. Augustyn, et al. Expires April 2003 16 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 3. Augustyn, et al., "Requirements for Virtual Private LAN Services (VPLS)", Work in progress, October 2002. 4. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5. Andersson, L., Madsen, T., "PPVPN Terminology", Work in progress, June 2002. 6. Andersson, et al., "PPVPN L2 Framework", Work in progress, August 2002. 7. Nagarajan, et al., " Generic Requirements for Provider Provisioned VPN ", Work in progress, October 2002. 8. ANSI/IEEE Std 802.1D 1998 Edition, "Media Access Control (MAC) Bridges", 1998. 9. IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998. 10. IEEE Standard 802.1u-2001, "IEEE Standard for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks - Amendment 1: Technical and editorial corrections", 2001. 11. IEEE Standard 802.1v-2001, "IEEE Standard for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks - Amendment 2: VLAN Classification by Protocol and Port", 2001. 15 Acknowledgments We would like to acknowledge extensive comments provided by Loa Anderson, Joel Halpern, Eric Rosen, and Ali Sajassi. The authors, also, wish to extend appreciations to their respective employers and various other people who volunteered to review this work and provided feedback. 16 Editors' Addresses Waldemar Augustyn Email: waldemar@nxp.com Yetik Serbest SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 Email: serbest@tri.sbc.com Augustyn, et al. Expires April 2003 17 draft-augustyn-ppvpn-l2vpn-requirements-01.txt October 2002 Full Copyright Statement "Copyright (C) The Internet Society (2001). 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 in 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." Augustyn, et al. Expires April 2003 18