[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

PPVPN Working Group                                        Waldemar Augustyn
Internet Draft
Document: draft-augustyn-ppvpn-l2vpn-requirements-00.txt         Giles Heron
Category: Informational                                   PacketExchange Ltd

June 2002                                                      Vach Kompella
Expires: December 2002                                      TiMetra Networks

                                                               Marc Lasserre
                                                         Riverstone Networks

                                                              Pascal Menezes

                                                           Hamid Ould-Brahim
                                                             Nortel Networks

                                                          Tissa Senevirathne

     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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   For potential updates to the above required-text see:

Augustyn, et. al.       Expires December 2002                       1

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

Summary for Sub-IP related Internet Drafts


   See references.


   This ID is intended for the PPVPN WG.


   PPVPN deals with provider provisioned VPNs.  This document describes
   requirements for L2 Virtual Private Network Services.


   This document represents the evolution of draft-ietf-ppvpn-vpls-
   requirements-00.txt to include requirements for Virtual Private Wire

1  Abstract

   This draft describes service requirements for L2 Virtual Private
   Networks. It covers non-broadcast point to point and point to
   multipoint 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-00.txt [3].

2  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC-2119 [4].

3  Definitions

3.1 L2VPN

   A network service offered by Service Providers where packets are
   forwarded based on layer 2 information (such as FR, ATM, or MAC)
   and/or on the basis of the incoming link.  The term is also used,

Augustyn, et al.        Expires December 2002                       2

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

   when clear from the context, to refer to a particular instance of
   L2VPN service.

3.2 L2VPN System

   A collection of communication equipment, related protocols, and
   configuration elements that implements L2VPN Services.

3.3 VSI

   Virtual Switching Instance. A virtual layer 2 forwarding entity that
   is closed to a L2VPN membership. VSI forwarding can be based on MAC
   addresses, VLAN tags, policies, topologies, filters, QoS parameters,
   and other relevant information on a per L2VPN basis.

3.4 VPWS

   Virtual Private WAN Service, a case of L2VPN implementing a non-
   broadcast point to  point, or point to multipoint VPN. The term is
   also used, when clear from the context, to refer to a particular
   instance of VPWS service.

3.5 VPLS

   Virtual Private LAN Service, a case of L2VPN service distinguished
   by the support of L2 broadcast.  The term is also used, when clear
   from the context, to refer to a particular instance of VPLS service.

   A VPLS service allows the connection of multiple sites in a single
   bridged domain over a provider managed IP or MPLS network. All
   customer sites in the VPLS appear to be on the same LAN regardless
   of their location.

3.6 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.

3.7 VLAN

   A customer VLAN identification using some scheme such as IEEE 802.1Q
   tags, port configuration or any other means. A VPLS service can be
   extended to recognize customer VLANs as specified in 6.1 .

Augustyn, et al.        Expires December 2002                       3

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

3.8 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  Introduction

   This document describes the service requirements for Layer 2 Virtual
   Private Networks.

4.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

   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

4.2 L2VPN 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.

   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.

4.2.1 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.

Augustyn, et al.        Expires December 2002                       4

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

   A variation of that service is a point to multipoint, non-broadcast
   L2VPN.  It differs only slightly from a more common point to point
   VPN by offering more than one end point.  The behavior of the VPN,
   however, remains point to point by nature.  The topology of such
   VPNs can be fully meshed or partially meshed.  In the latter case,
   certain CEs, spokes of a hub, will see the VPN as a point to point
   circuit. The VPN does not support broadcast and does not attempt to
   interpret broadcast addresses.  It is the responsibility of a CE
   device to replicate packets in case broadcast emulation is

4.2.2 Virtual Private LAN Service

   The VPLS service attempts to emulate a broadcast domain, LAN-like,
   behavior for the members of the VPN.  The VPN provides the
   capability to replicate packets and to interpret broadcast and
   multicast addresses according to their meaning.

5  L2VPN Reference Model

   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

    +-----+                                       +-----+
    + 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

5.1 Point to point L2VPN

   The PE devices provide a logical interconnect such that a pair of CE
   devices appear to be connected by a single logical L2 circuit.

Augustyn, et al.        Expires December 2002                       5

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

   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 point to
   point case.

   The CE-to-PE links can either be direct physical links, e.g.
   100BaseTX, or logical links, e.g. ATM PVC, T1/E1 TDM, or RFC1490-
   encapsulated link, over which L2 traffic is carried.  The flavor of
   the CE-PE L2 link is typically the same on each end, but it can be
   different in case a proper interworking is provided e.g. ATM/FR
   interworking, ARP mediation, or similar.

   The PE-to-PE links carry tunneled L2 frames using different
   tunneling technologies (e.g., GRE, IPSec, MPLS, L2TP, etc.).

   Each PE device is responsible for allocating customer L2 frames to
   the appropriate L2VPN and for proper forwarding to the intended end

5.2 Point to multipoint, non-broadcast L2VPN

   A non-broadcast point to multipoint L2VPN behaves similarly to a
   point to point L2VPN.  It differs in that there is more than one L2
   destination reachable via a L2VPN instance.  To the CE, it looks
   like a collection of point to point circuits.  The VPN does not
   provide for packet replication, nor does it recognize broadcast
   addresses.  A CE can emulate broadcast by explicit replication by
   each CE.

   In the diagram above, L2VPN A can represent a point to multipoint
   L2VPN.  The L2VPN topology for the customer devices, CE1, CE2, and
   CE3 can be hub and spoke or a full mesh.  In the latter case, the
   connectivity is frequently referred to as multipoint to multipoint.

5.3 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 logical Ethernet bridge. 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.

Augustyn, et al.        Expires December 2002                       6

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

   The CE-to-PE links can either be direct physical links, e.g.
   100BaseTX, or logical links, e.g. ATM PVC, T1/E1 TDM, or RFC1490-
   encapsulated link, over which bridged Ethernet traffic is carried.

   The PE-to-PE links carry tunneled Ethernet frames using different
   tunneling technologies (e.g., 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

6  VPLS General Requirements

6.1 Layer 2 Domain representation

   A L2VPN system MUST distinguish different customer domains. Each of
   these customer domains MUST appear as a L2 network.

   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. Each L2VPN MUST carry a
   unique identification within a L2VPN system. It is RECOMMENDED that
   L2VPN identification be globally unique.

   A provider's implementation of a L2VPN system SHOULD NOT constrain
   the customer's ability to configure VPN topologies, or Layer 2
   parameters related to the supported L2 protocol.

   In case of VPLS, each domain MUST be capable of learning and
   forwarding based on MAC addresses thus emulating an Ethernet virtual
   switch 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.

6.2 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

     o point-to-point

Augustyn, et al.        Expires December 2002                       7

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

     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 topology employed, the service to the customers
   MUST retain the connectivity type implied by the type of L2VPN. For
   example, a non-broadcast point to multipoint VPN should allow point
   to multipoint VPN 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.

6.3 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 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.

6.4 Policy Constraints

   A L2VPN system MAY employ policy constraints governing various
   interconnection attributes for L2VPN domains. Typical attributes

     o Selection of available network infrastructure
     o QoS services needed
     o Protection services needed
     o Availability of higher level service access points (see 9.7 )

   Policy attributes SHOULD be advertised via the L2VPN system's
   control plane.

6.5 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

Augustyn, et al.        Expires December 2002                       8

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

   implementations, the PE nodes may be comprised of several physical
   devices. 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.

6.6 PE-PE Interconnection and Tunneling

   A L2VPN system MUST provide for 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 MPLS, IP in IP tunnels, variations of
   802.1Q, etc.  Regardless of the choice, the existence of the tunnels
   and their operations MUST be transparent to the customers.

6.7 PE-CE Interconnection and Profiles

   A L2VPN system MUST provide for connectivity between PE nodes and CE
   nodes.  That connectivity is referred to as CE access connection,
   access connection, or simply access. Access connections MAY span
   networks of other providers or public networks.

   There are several choices for implementing access. Some popular
   choices include Ethernet, ATM (DSL), Frame Relay, MPLS-based virtual
   circuits etc.

   In case of VPLS, the access connection MUST use Ethernet frames as
   the Service Protocol Data Unit (SPDU).

   A CE access connection MUST be bi-directional in nature.

   PE devices MAY support multiple CE access connections on a single
   physical interface. In such cases, PE devices MUST NOT rely on
   customer controlled parameters, such as VLAN tags etc., for
   distinguishing between different access connections.

   A CE access connection, whether direct or virtual, MUST maintain all
   committed characteristics of the customer traffic, such as QoS,
   priorities etc. The characteristics of a CE access connection are
   only applicable to that connection.

7  Control Plane Requirements

7.1 Provider Edge Signaling

Augustyn, et al.        Expires December 2002                       9

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

   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.

7.2 L2VPN Membership Discovery

   The control protocols SHOULD provide methods to discover the PEs
   which connect CEs forming a L2VPN.

7.3 Support for Layer 2 control protocols

   A L2VPN system MUST ensure that loops be prevented. This can be
   accomplished through a loop free topologies or appropriate
   forwarding rules.  In case of VPLS, control protocols such as
   Spanning Tree or similar could be employed.

   The L2VPN system's control protocols SHOULD allow transparent
   operation of Layer 2 control protocols employed by customers.

   In case of VPLS, a VPLS system's control protocols MAY use
   indications from customer STP to improve the operation of a VPLS.

7.4 Scaling Requirements

   In a L2VPN system, the control plane traffic increases with the
   growth of L2VPN membership. Similarly, the control plane traffic
   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 with 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.

8  Data Plane Requirements

8.1 Transparency

Augustyn, et al.        Expires December 2002                      10

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

   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.

8.2 Layer 2 Virtual Switching Instance

   L2VPN 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 DLCI, VPI/VCI, MAC addresses, VLAN tags (if
   supported), etc. as well as local policies.

   L2VPN Provider Edge devices MUST have capabilities to classify
   incoming customer traffic into the appropriate VSI.

   In case of VPLS, Each VSI MUST have flooding capabilities for its
   Broadcast Domain to facilitate proper forwarding of Broadcast,
   Multicast and Unknown Unicast customer traffic.

8.3 Minimum MTU

   The L2VPN 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. In case of VPLS, if VLANs are supported, all VLANs within a
   given VPLS MUST inherit the same MTU size.

8.4 QoS and packet re-ordering

   A L2VPN system SHOULD have capabilities to enforce QoS parameters.

   The queuing and forwarding policies SHOULD preserve packet order for
   packets with the same QoS parameters.

   The service SHOULD not duplicate packets.

8.5 Additional requirements for VPLS systems

8.5.1 Broadcast Domain

Augustyn, et al.        Expires December 2002                      11

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

   The Broadcast Domain is defined as the flooding scope of a Layer 2
   network. A separate Broadcast Domain MUST be maintained for each

   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

8.5.2 MAC address learning

   A VPLS service SHOULD derive all topology and forwarding information
   from packets originating at customer sites.  Typically, MAC
   addresses 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.

8.5.3 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 all destinations. However, a
   VPLS system MAY employ multicast snooping techniques, in which case
   multicast packets SHOULD be forwarded only to their intended

   Unicast packets MUST be forwarded to their intended destinations.

   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

Augustyn, et al.        Expires December 2002                      12

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

8.5.4 Multilink Access

   The VPLS service SHOULD support multilink access for CE devices.
   The VPLS service MAY support multihome access for CE devices.

8.5.5 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.

8.5.6 Support for MAC Services

   VPLS are REQUIRED to provide MAC service compliant with IEEE 802.1D
   specification [5] 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 [6], [7], and [8].

   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

9  Management and Operations Requirements

9.1 L2VPN configuration and monitoring

   A L2VPN system MUST have capabilities to configure, manage, and
   monitor its different components.

   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.

Augustyn, et al.        Expires December 2002                      13

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

9.2 L2VPN operations

   The operations of a L2VPN systems is controlled by an administrative
   authority, or 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 mechanism MUST NOT
   assume any particular structure of the different admins.  For
   example the L2VPN should not be relying on admins forming a

   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.

9.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

9.4 Customer traffic policing

   The L2VPN service SHOULD provide the ability to police and/or shape
   customer traffic entering and leaving the L2VPN system.

9.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

Augustyn, et al.        Expires December 2002                      14

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

9.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

9.7 L3, and higher, service access point.

   The L2VPN service SHOULD allow for a Provider based Service Access
   Point for orderly injection of L3 or higher services to the
   customers' VPLS segments.

   In particular, the L2VPN 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

9.8 Testing

   The L2VPN service 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.

9.9 Learning information from customer devices

   The L2VPN service SHOULD provide means for limiting the amount of
   information learned from customer devices.

   For example, VPLS implementations typically limit the number of MAC
   addresses learned from the customers' devices.

10 Security Requirements

10.1 Traffic separation

   L2VPN system MUST provide traffic separation between different L2VPN

   In case of VPLS, if VLANs are supported, the system MUST provide
   traffic separation between customer VLANs within each VPLS domain.

Augustyn, et al.        Expires December 2002                      15

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

10.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, short/long packets, spoofed
   management packets, spoofed VLAN tags, high volume traffic, etc.

   Additionally, L2VPN system MUST be immune to misconfigured or
   maliciously set up customer network topologies.  These include
   customer side loops, backdoor links between sites, etc.

   The L2VPN infrastructure devices MUST NOT be accessible from the

10.3 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.

11 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.

   3. Augustyn, et al., "Requirements for Virtual Private LAN Services
      (VPLS)", Work in progress, March 2002.

   4. Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   5. IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan
      Area Networks: Virtual Bridged Local Area Networks", 1998.

   6. IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan
      Area Networks: Virtual Bridged Local Area Networks", 1998.

   7. 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.

Augustyn, et al.        Expires December 2002                      16

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

   8. 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.

12 Acknowledgments

   We would like to acknowledge extensive comments provided by Loa
   Anderson, Joel Halpern, and Eric Rosen. The authors, also, wish to
   extend appreciations to their respective employers and various other
   people who volunteered to review this work and provided feedback.

13 Authors' Addresses

   Waldemar Augustyn
   Email: waldemar@nxp.com

   Giles Heron
   PacketExchange Ltd.
   The Truman Brewery
   91 Brick Lane
   London E1 6QL
   United Kingdom
   Email: giles@packetexchange.net

   Vach Kompella
   TiMetra Networks
   274 Ferguson Dr.
   Mountain View, CA 94043
   Email: vkompella@timetra.com

   Marc Lasserre
   Riverstone Networks
   5200 Great America Pkwy
   Santa Clara, CA 95054
   Phone: 408-878-6500
   Email: marc@riverstonenet.com

   Pascal Menezes
   Phone: 206-686-2001
   Email: pascal.menezes@terabeam.com

Augustyn, et al.        Expires December 2002                      17

            draft-augustyn-ppvpn-l2vpn-requirements-00.txt   June 2002

   Hamid Ould-Brahim
   Nortel Networks
   P.O. Box 3511 Station C
   Ottawa ON K1Y 4H7
   Phone: 613-765-3418
   Email: hbrahim@nortelnetworks.com

   Tissa Senevirathne
   Email: tsenevir@hotmail.com

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

   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

Augustyn, et al.        Expires December 2002                      18

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/