GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4665

Network Working Group W. Augustyn, Ed. Request for Comments: 4665 Y. Serbest, Ed. Category: Informational AT&T

                                                        September 2006
                 Service Requirements for Layer 2
           Provider-Provisioned Virtual Private Networks

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document provides requirements for Layer 2 Provider-Provisioned
 Virtual Private Networks (L2VPNs).  It first provides taxonomy and
 terminology and states generic and general service requirements.  It
 covers point-to-point VPNs, referred to as Virtual Private Wire
 Service (VPWS), as well as multipoint-to-multipoint VPNs, also known
 as Virtual Private LAN Service (VPLS).  Detailed requirements are
 expressed from both a customer as well as a service provider
 perspectives.

Augustyn & Serbest Informational [Page 1] RFC 4665 Service Requirements for L2VPNs September 2006

Table of Contents

 1. Introduction ....................................................4
    1.1. Scope of This Document .....................................4
    1.2. Outline ....................................................5
 2. Conventions used in this document ...............................5
 3. Contributing Authors ............................................5
 4. Definitions and Taxonomy ........................................5
    4.1. Definitions ................................................5
    4.2. Taxonomy of L2VPN Types ....................................6
    4.3. VPWS .......................................................6
    4.4. VPLS .......................................................7
 5. Service Requirements Common to Customers and Service Providers ..7
    5.1. Scope of emulation .........................................8
    5.2. Traffic Types ..............................................8
    5.3. Topology ...................................................8
    5.4. Isolated Exchange of Data and Forwarding Information .......9
    5.5. Security ...................................................9
         5.5.1. User Data Security .................................10
         5.5.2. Access Control .....................................10
    5.6. Addressing ................................................11
    5.7. Quality of Service ........................................11
         5.7.1. QoS Standards ......................................11
         5.7.2. Service Models .....................................11
    5.8. Service Level Specifications ..............................12
    5.9. Protection and Restoration ................................12
    5.10. CE-to-PE and PE-to-PE Link Requirements ..................12
    5.11. Management ...............................................12
    5.12. Interoperability .........................................12
    5.13. Inter-working ............................................13
 6. Customer Requirements ..........................................13
    6.1. Service Provider Independence .............................13
    6.2. Layer 3 Support ...........................................13
    6.3. Quality of Service and Traffic Parameters .................14
    6.4. Service Level Specification ...............................14
    6.5. Security ..................................................14
         6.5.1. Isolation ..........................................14
         6.5.2. Access Control .....................................14
         6.5.3. Value-Added Security Services ......................15
    6.6. Network Access ............................................15
         6.6.1. Physical/Link Layer Technology .....................15
         6.6.2. Access Connectivity ................................15
    6.7. Customer Traffic ..........................................17
         6.7.1. Unicast, Unknown Unicast, Multicast, and
                Broadcast forwarding ...............................17
         6.7.2. Packet Re-ordering .................................17
         6.7.3. Minimum MTU ........................................17
         6.7.4. End-point VLAN Tag Translation .....................18

Augustyn & Serbest Informational [Page 2] RFC 4665 Service Requirements for L2VPNs September 2006

         6.7.5. Transparency .......................................18
    6.8. Support for Layer 2 Control Protocols .....................18
    6.9. CE Provisioning ...........................................19
 7. Service Provider Network Requirements ..........................19
    7.1. Scalability ...............................................19
         7.1.1. Service Provider Capacity Sizing Projections .......19
         7.1.2. Solution-Specific Metrics ..........................19
    7.2. Identifiers ...............................................19
    7.3. Discovering L2VPN Related Information .....................19
    7.4. Quality of Service (QoS) ..................................20
    7.5. Isolation of Traffic and Forwarding Information ...........20
    7.6. Security ..................................................21
    7.7. Inter-AS/SP L2VPNs ........................................22
         7.7.1. Management .........................................22
         7.7.2. Bandwidth and QoS Brokering ........................22
    7.8. L2VPN Wholesale ...........................................23
    7.9. Tunneling Requirements ....................................23
    7.10. Support for Access Technologies ..........................23
    7.11. Backbone Networks ........................................24
    7.12. Network Resource Partitioning and Sharing Between
          L2VPNs ...................................................24
    7.13. Interoperability .........................................24
    7.14. Testing ..................................................25
    7.15. Support on Existing PEs ..................................25
 8. Service Provider Management Requirements .......................26
 9. Engineering Requirements .......................................26
    9.1. Control Plane Requirements ................................26
    9.2. Data Plane Requirements ...................................27
         9.2.1. Encapsulation ......................................27
         9.2.2. Responsiveness to Congestion .......................27
         9.2.3. Broadcast Domain ...................................27
         9.2.4. Virtual Switching Instance .........................27
         9.2.5. MAC Address Learning ...............................27
 10. Security Considerations .......................................28
 11. Acknowledgements ..............................................28
 12. References ....................................................29
    12.1. Normative References .....................................29
    12.2. Informative References ...................................29

Augustyn & Serbest Informational [Page 3] RFC 4665 Service Requirements for L2VPNs September 2006

1. Introduction

 This section describes the scope and outline of the document.

1.1. Scope of This Document

 This document provides requirements for provider-provisioned Layer 2
 Virtual Private Networks (L2VPN).  It identifies requirements that
 MAY apply to one or more individual approaches that a Service
 Provider (SP) may use for the provisioning of a Layer 2 VPN service.
 The content of this document makes use of the terminology defined in
 [RFC4026] and common components for deploying L2VPNs described in
 [RFC4664].
 The technical specifications to provide L2VPN services are outside
 the scope of this document.  The framework document [RFC4664] and
 several other documents, which explain technical approaches providing
 L2VPN services, such as [VPLS_LDP], [VPLS_BGP], and [IPLS], are
 available to cover this aspect.
 This document describes requirements for two types of L2VPNs: (1)
 Virtual Private Wire Service (VPWS), and (2) Virtual Private LAN
 Service (VPLS).  The approach followed in this document distinguishes
 L2VPN types as to how the connectivity is provided (point-point or
 multipoint-multipoint), as detailed in [RFC4664].
 This document is intended as a "checklist" of requirements that will
 provide a consistent way to evaluate and document how well each
 individual approach satisfies specific requirements.  The
 applicability statement document for each individual approach should
 document the results of this evaluation.
 In the context of provider-provisioned VPNs, there are two entities
 involved in operation of such services, the Provider and the
 Customer.  The Provider engages in a binding agreement with the
 Customer as to the behavior of the service in a normal situation as
 well as in exceptional situations.  Such agreement is known as
 Service Level Specification (SLS), which is part of the Service Level
 Agreement (SLA) established between the Provider and the Customer.
 A proper design of L2VPNs aids formulation of SLSes in that it
 provides means for proper separation between Customer Edge (CE) and
 Provider Edge (PE), allows proper execution of the SLS offer, and
 supports a flexible and rich set of capabilities.
 This document provides requirements from both the Provider's and the
 Customer's point of view.  It begins with common customer's and
 service provider's point of view, followed by a customer's

Augustyn & Serbest Informational [Page 4] RFC 4665 Service Requirements for L2VPNs September 2006

 perspective, and concludes with specific needs of an SP.  These
 requirements provide high-level L2VPN features expected by an SP in
 provisioning L2VPNs, which include SP requirements for security,
 privacy, manageability, interoperability, and scalability.

1.2. Outline

 The outline of the rest of this document is as follows.  Section 4
 provides definitions and taxonomy.  Section 5 provides common
 requirements that apply to both customer and SP, respectively.
 Section 6 states requirements from a customer perspective.  Section 7
 states network requirements from an SP perspective.  Section 8 states
 SP management requirements.  Section 9 describes the engineering
 requirements, particularly control and data plane requirements.
 Section 10 provides security considerations.  Section 11 lists
 acknowledgements.  Section 12 provides a list of references cited
 herein.

2. Conventions used in this document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

3. Contributing Authors

 This document was the combined effort of several individuals.  The
 following are the authors that contributed to this document:
 Waldemar Augustyn
 Marco Carugi
 Giles Heron
 Vach Kompella
 Marc Lasserre
 Pascal Menezes
 Hamid Ould-Brahim
 Tissa Senevirathne
 Yetik Serbest

4. Definitions and Taxonomy

4.1. Definitions

 The terminology used in this document is defined in [RFC4026].  The
 L2VPN framework document [RFC4664] further describes these concepts
 in the context of a reference model that defines layered service
 relationships between devices and one or more levels of tunnels.

Augustyn & Serbest Informational [Page 5] RFC 4665 Service Requirements for L2VPNs September 2006

4.2. Taxonomy of L2VPN Types

 The requirements distinguish two major L2VPN models, a Virtual
 Private Wire Service (VPWS), and a Virtual Private LAN Service
 (VPLS).
 The following diagram shows an L2VPN reference model.
 +-----+                                       +-----+
 + CE1 +--+                                +---| CE2 |
 +-----+  |    ........................    |   +-----+
 L2VPN A  |  +----+                +----+  |   L2VPN A
          +--| PE |--- Service  ---| PE |--+
             +----+    Provider    +----+
            /  .       Backbone       .  \     -   /\-_
 +-----+   /   .          |           .   \   / \ /   \     +-----+
 + CE4 +--+    .          |           .    +--\ Access \----| CE5 |
 +-----+       .        +----+        .       | Network |   +-----+
 L2VPN B       .........| PE |.........        \       /    L2VPN B
                        +----+     ^            -------
                          |        |
                          |        |
                       +-----+     |
                       | CE3 |     +-- Logical switching instance
                       +-----+
                       L2VPN A
                   Figure 1.  L2VPN Reference Model

4.3. VPWS

 The PE devices provide a logical interconnect such that a pair of CE
 devices appears to be connected by a single logical Layer 2 circuit.
 PE devices act as Layer 2 circuit switches.  Layer 2 circuits are
 then mapped onto tunnels in the SP network.  These tunnels can either
 be specific to a particular VPWS, or be shared among several
 services.  VPWS applies for all services, including Ethernet, ATM,
 Frame Relay, etc.  In Figure 1, L2VPN B represents a VPWS case.
 Each PE device is responsible for allocating customer Layer 2 frames
 to the appropriate VPWS and for proper forwarding to the intended
 destinations.

Augustyn & Serbest Informational [Page 6] RFC 4665 Service Requirements for L2VPNs September 2006

4.4. VPLS

 In case of VPLS, the PE devices provide a logical interconnect such
 that CE devices belonging to a specific VPLS appear to be connected
 by a single LAN.  End-to-end VPLS consists of a bridge module and a
 LAN emulation module ([RFC4664]).  A VPLS can contain a single VLAN
 or multiple VLANs ([IEEE_802.1Q]).  A variation of this service is
 IPLS ([RFC4664]), which is limited to supporting only customer IP
 traffic.
 In a VPLS, a customer site receives Layer 2 service from the SP.  The
 PE is attached via an access connection to one or more CEs.  The PE
 performs forwarding of user data packets based on information in the
 Layer 2 header, such as a MAC destination address.  In Figure 1,
 L2VPN A represents a VPLS case.
 The details of VPLS reference model, which we summarize here, can be
 found in [RFC4664].  In VPLS, the PE can be viewed as containing a
 Virtual Switching Instance (VSI) for each L2VPN that it serves.  A CE
 device attaches, possibly through an access network, to a bridge
 module of a PE.  Within the PE, the bridge module attaches, through
 an Emulated LAN Interface to an Emulated LAN.  For each VPLS, there
 is an Emulated LAN instance.  The Emulated LAN consists of VPLS
 Forwarder module (one per PE per VPLS service instance) connected by
 pseudo wires (PW), where the PWs may be traveling through Packet
 Switched Network (PSN) tunnels over a routed backbone.  VSI is a
 logical entity that contains a VPLS forwarder module and part of the
 bridge module relevant to the VPLS service instance [RFC4664].
 Hence, the VSI terminates PWs for interconnection with other VSIs and
 also terminates Attachment Circuits (ACs) (see [RFC3985] for
 definition) for accommodating CEs.  A VSI includes the forwarding
 information base for an L2VPN [RFC4664] which is the set of
 information regarding how to forward Layer 2 frames received over the
 AC from the CE to VSIs in other PEs supporting the same L2VPN service
 (and/or to other ACs), and it contains information regarding how to
 forward Layer 2 frames received from PWs to ACs.  Forwarding
 information bases can be populated dynamically (such as by source MAC
 address learning) or statically (e.g., by configuration).  Each PE
 device is responsible for proper forwarding of the customer traffic
 to the appropriate destination(s) based on the forwarding information
 base of the corresponding VSI.

5. Service Requirements Common to Customers and Service Providers

 This section contains requirements that apply to both the customer
 and the provider, or that are of an otherwise general nature.

Augustyn & Serbest Informational [Page 7] RFC 4665 Service Requirements for L2VPNs September 2006

5.1. Scope of emulation

 L2VPN protocols SHOULD NOT interfere with existing Layer 2 protocols
 and standards of the Layer 2 network the customer is managing.  If
 they impact customer Layer 2 protocols that are sent over the VPLS,
 then these impacts MUST be documented.
 Some possibly salient differences between VPLS and a real LAN are:
  1. 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.
  1. VPLS frames can get duplicated if the PW sequencing option isn't

turned on. The data frames on the PWs are sent in IP datagrams,

   and under certain failure scenarios, IP networks can duplicate
   packets.  If the PW data transmission protocol does not ensure
   sequence of data packets, frames can be duplicated or received out
   of sequence.  If the customer's Bridge Protocol Data Unit (BPDU)
   frames are sent as data packets, then BPDU frames can be duplicated
   or mis-sequenced, although this may not create any problems for
   Real-Time Streaming Protocol (RSTP).
  1. 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.
  1. 802.3x Pause frames will not be transported over a VPLS, as the

bridge module ([RFC4664]) in the PE terminates them.

  1. Since the IPLS solution aims at transporting encapsulated traffic

(rather than Layer 2 frames themselves), the IPLS solution is NOT

   REQUIRED to preserve the Layer 2 Header transparently from CE to
   CE.  For example, Source MAC address will probably not be preserved
   by the IPLS solution.

5.2. Traffic Types

 A VPLS MUST support unicast, multicast, and broadcast traffic.
 Support for efficient replication of broadcast and multicast traffic
 is highly desirable.

5.3. Topology

 A SP network may be realized using one or more network tunnel
 topologies to interconnect PEs, ranging from simple point-to-point to
 distributed hierarchical arrangements.  The typical topologies
 include:

Augustyn & Serbest Informational [Page 8] RFC 4665 Service Requirements for L2VPNs September 2006

  1. Point-to-point
  2. Point-to-multipoint, a.k.a. hub and spoke
  3. Any-to-any, a.k.a. full mesh
  4. Mixed, a.k.a. partial mesh
  5. Hierarchical
 Regardless of the SP topology employed, the service to the customers
 MUST retain the connectivity type implied by the type of L2VPN.  For
 example, a VPLS MUST allow multipoint-to-multipoint connectivity even
 if it is implemented with point-to-point circuits.  This requirement
 does not imply that all traffic characteristics (such as bandwidth,
 QoS, delay, etc.) necessarily be the same between any two end points
 of an L2VPN.  It is important to note that SLS requirements of a
 service have a bearing on the type of topology that can be used.
 To the extent possible, an L2VPN service SHOULD be capable of
 crossing multiple administrative boundaries.
 To the extent possible, the L2VPN services SHOULD be independent of
 access network technology.

5.4. Isolated Exchange of Data and Forwarding Information

 L2VPN solutions SHALL define means that prevent CEs in an L2VPN from
 interaction with unauthorized entities.
 L2VPN solutions SHALL avoid introducing undesired forwarding
 information that could corrupt the L2VPN forwarding information base.
 A means to constrain or isolate the distribution of addressed data to
 only those VPLS sites determined either by MAC learning and/or
 configuration MUST be provided.
 The internal structure of an L2VPN SHOULD not be advertised or
 discoverable from outside that L2VPN.

5.5. Security

 A range of security features MUST be supported by the suite of L2VPN
 solutions.  Each L2VPN solution MUST state which security features it
 supports and how such features can be configured on a per-customer
 basis.
 A number of security concerns arise in the setup and operation of an
 L2VPN, ranging from misconfigurations to attacks that can be launched
 on an L2VPN and can strain network resources such as memory space,
 forwarding information base table, bandwidth, and CPU processing.

Augustyn & Serbest Informational [Page 9] RFC 4665 Service Requirements for L2VPNs September 2006

 This section lists some potential security hazards that can result
 due to mis-configurations and/or malicious attacks.  There MUST be
 methods available to protect against the following situations.
  1. Protocol attacks

o Excessive protocol adjacency setup/teardown

   o Excessive protocol signaling/withdrawal
  1. Resource Utilization

o Forwarding plane replication (VPLS)

   o Looping (VPLS primarily)
   o MAC learning table size limit (VPLS)
  1. Unauthorized access

o Unauthorized member of VPN

   o Incorrect customer interface
   o Incorrect service delimiting VLAN tag
   o Unauthorized access to PE
  1. Tampering with signaling

o Incorrect FEC signaling

   o Incorrect PW label assignment
   o Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.)
  1. Tampering with data forwarding

o Incorrect MAC learning entry

   o Incorrect PW label
   o Incorrect AC identifier
   o Incorrect customer facing encapsulation
   o Incorrect PW encapsulation
   o Hijacking PWs using the wrong tunnel
   o Incorrect tunnel encapsulation

5.5.1. User Data Security

 An L2VPN solution MUST provide traffic separation between different
 L2VPNs.
 In case of VPLS, VLAN Ids MAY be used as service delimiters.  When
 used in this manner, they MUST be honored and traffic separation MUST
 be provided.

5.5.2. Access Control

 An L2VPN solution MAY also have the ability to activate the
 appropriate filtering capabilities upon request of a customer.

Augustyn & Serbest Informational [Page 10] RFC 4665 Service Requirements for L2VPNs September 2006

5.6. Addressing

 An L2VPN solution MUST support overlapping addresses of different
 L2VPNs.  For instance, customers MUST NOT be prevented from using the
 same MAC addresses with different L2VPNs.  If a service provider uses
 VLANs as service delimiters, the L2VPN solution MUST ensure that VLAN
 Ids cannot overlap.  If VLANs are not used as service delimiters,
 L2VPN solutions MAY allow VLAN Ids to overlap.

5.7. Quality of Service

 To the extent possible, L2VPN QoS SHOULD be independent of the access
 network technology.

5.7.1. QoS Standards

 As provided in [RFC3809], an L2VPN SHALL be able to support QoS in
 one or more of the following already standardized modes:
  1. Best Effort (support mandatory for all provider-provisioned

VPN types)

  1. Aggregate CE Interface Level QoS (i.e., 'hose' level)
  1. Site-to-site, or 'pipe' level QoS
 Note that all cases involving QoS MAY require that the CE and/or PE
 perform shaping and/or policing.
 Mappings or translations of Layer 2 QoS parameters into PSN QoS
 (e.g., DSCPs or MPLS EXP field) as well as QoS mapping based on VC
 (e.g., FR/ATM or VLAN) MAY be performed in order to provide QoS
 transparency.  The actual mechanisms for these mappings or
 translations are outside the scope of this document.  In addition,
 the Diffserv support of underlying tunneling technologies (e.g.,
 [RFC3270] or [RFC3308]) and the Intserv model ([RFC2205]) MAY be
 used.  As such, the L2VPN SLS requirements SHOULD be supported by
 appropriate core mechanisms.

5.7.2. Service Models

 A service provider may desire to offer QoS service to a customer for
 at least the following generic service types: managed access VPN
 service or an edge-to-edge QoS service.  The details of the service
 models can be found in [RFC3809] and in [RFC4031].
 In L2VPN service, both DSCP ([RFC2474]) and 802.1p ([IEEE_802.1D])
 fields may be used for this purpose.

Augustyn & Serbest Informational [Page 11] RFC 4665 Service Requirements for L2VPNs September 2006

5.8. Service Level Specifications

 For an L2VPN service, the capabilities for Service Level
 Specification (SLS) monitoring and reporting stated in [RFC3809]
 SHOULD be provided.

5.9. Protection and Restoration

 The L2VPN service infrastructure SHOULD provide redundant paths to
 ensure high availability.  The reaction to failures SHOULD result in
 an attempt to restore the service using alternative paths.
 The intention is to keep the restoration time small.  The restoration
 time MUST be less than the time it takes the CE devices, or customer
 Layer 2 control protocols as well as Layer 3 routing protocols, to
 detect a failure in the L2VPN.

5.10. CE-to-PE and PE-to-PE Link Requirements

 The CE-to-PE links MAY be
  1. direct physical links (e.g., 100BaseTX, and T1/E1 TDM),
  2. logical links (e.g., ATM PVC, and RFC2427-encapsulated link),
  3. transport networks carrying Ethernet,
  4. a Layer 2 tunnel that goes through a Layer 3 network (e.g., L2TP

sessions).

 Layer 2 frames MAY be tunneled through a Layer 3 backbone from PE to
 PE, using one of a variety of tunneling technologies (e.g., IP-in-IP,
 GRE, MPLS, L2TP, etc.).

5.11. Management

 Standard interfaces to manage L2VPN services MUST be provided (e.g.,
 standard SNMP MIB Modules).  These interfaces SHOULD provide access
 to configuration, verification and runtime monitoring protocols.
 Service management MAY include the TMN 'FCAPS' functionalities, as
 follows: Fault, Configuration, Accounting, Performance, and Security,
 as detailed in [ITU_Y.1311.1].

5.12. Interoperability

 Multi-vendor interoperability, which corresponds to similar network
 and service levels among different implementations, at the network
 element SHOULD be guaranteed.  This will likely rely on the
 completeness of the corresponding standard.

Augustyn & Serbest Informational [Page 12] RFC 4665 Service Requirements for L2VPNs September 2006

 The technical solution MUST be multi-vendor interoperable, not only
 within the SP network infrastructure, but also with the customer's
 network equipment and services making use of the L2VPN service.
 A L2VPN solution SHOULD NOT preclude different access technologies.
 For instance, customer access connections to an L2VPN service MAY be
 different at different CE devices (e.g., Frame Relay, ATM, 802.1D,
 MPLS).

5.13. Inter-working

 Inter-working scenarios among different solutions providing L2VPN
 services are highly desirable.  It is possible to have cases that
 require inter-working or interconnection between customer sites,
 which span network domains with different L2VPN solutions or
 different implementations of the same approach.  Inter-working SHOULD
 be supported in a scalable manner.
 Inter-working scenarios MUST consider at least traffic isolation,
 security, QoS, access, and management aspects.  This requirement is
 essential in the case of network migration, to ensure service
 continuity among sites belonging to different portions of the
 network.

6. Customer Requirements

 This section captures requirements from a customer perspective.

6.1. Service Provider Independence

 Customers MAY require L2VPN service that spans multiple
 administrative domains or SP networks.  Therefore, an L2VPN service
 MUST be able to span multiple AS and SP networks but still to act and
 to appear as a single, homogeneous L2VPN from a customer point of
 view.
 A customer might also start with an L2VPN provided in a single AS
 with a certain SLS but then ask for an expansion of the service
 spanning multiple ASes and/or multiple-SPs.  In this case, as well as
 for all kinds of multi-AS and multiple-SP L2VPNs, L2VPN service
 SHOULD be able to deliver the same SLS to all sites in a VPN
 regardless of the AS/SP to which it homes.

6.2. Layer 3 Support

 With the exception of IPLS, an L2VPN service SHOULD be agnostic to
 customer's Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated
 within Layer 2 frames.

Augustyn & Serbest Informational [Page 13] RFC 4665 Service Requirements for L2VPNs September 2006

 IPLS MUST allow transport of customer's IPv4 and IPv6 traffic
 encapsulated within Layer 2 frames.  IPLS SHOULD also allow CEs to
 run ISIS and MPLS protocols transparently among them when those are
 used in conjunction with IP.

6.3. Quality of Service and Traffic Parameters

 QoS is expected to be an important aspect of an L2VPN service for
 some customers.
 A customer requires that the L2VPN service provide the QoS applicable
 to his or her application, which can range from PWs (e.g., SONET
 emulation) to voice, interactive video, and multimedia applications.
 Hence, best-effort as well as delay and loss sensitive traffic MUST
 be supported over an L2VPN service.  A customer application SHOULD
 experience consistent QoS independent of the access network
 technology used at different sites connected to the same L2VPN.

6.4. Service Level Specification

 Most customers simply want their applications to perform well.  A SLS
 is a vehicle for a customer to measure the quality of the service
 that SP(s) provide.  Therefore, when purchasing a service, a customer
 requires access to the measures from the SP(s) that support the SLS.
 Standard interfaces to monitor usage of L2VPN services SHOULD be
 provided (e.g., standard SNMP MIB Modules).

6.5. Security

6.5.1. Isolation

 An L2VPN solution MUST provide traffic as well as forwarding
 information base isolation for customers similar to that obtained in
 private lines, FR, or ATM services.
 An L2VPN service MAY use customer VLAN Ids as service delimiters.  In
 that case, they MUST be honored, and traffic separation MUST be
 provided.

6.5.2. Access Control

 An L2VPN solution MAY have the mechanisms to activate the appropriate
 filtering capabilities upon request of a customer.  For instance, MAC
 and/or VLAN filtering MAY be considered between CE and PE for a VPLS.

Augustyn & Serbest Informational [Page 14] RFC 4665 Service Requirements for L2VPNs September 2006

6.5.3. Value-Added Security Services

 An L2VPN solution MAY provide value-added security services such as
 encryption and/or authentication of customer packets, certificate
 management, and similar services.
 L2VPN services MUST NOT interfere with the security mechanisms
 employed at Layer 3 and higher layers by customers.  Layer 2 security
 mechanisms, such as 802.10b ([IEEE_802.10]) and 802.1AE
 ([IEEE_802.1AE]), MAY inhibit L2VPN services, when the service
 delimiting VLAN Ids are encrypted.

6.6. Network Access

 Every packet exchanged between the customer and the SP over the
 access connection MUST appear as it would on a private network
 providing an equivalent service to that offered by the L2VPN.

6.6.1. Physical/Link Layer Technology

 L2VPN solutions SHOULD support a broad range of physical and link-
 layer access technologies, such as PSTN, ISDN, xDSL, cable modem,
 leased line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless
 local loop, mobile radio access, etc.  The capacity and QoS
 achievable MAY be dependent on the specific access technology in use.

6.6.2. Access Connectivity

 Various types of physical connectivity scenarios MUST be supported,
 such as multi-homed sites, backdoor links between customer sites, and
 devices homed to two or more SP networks.  In case of VPLS, IEEE
 802.3ad-2000 link aggregation SHOULD be supported.  L2VPN solutions
 SHOULD support at least the types of physical or link-layer
 connectivity arrangements shown in Figures 2 - 4 (in addition to the
 case shown in Figure 1).  As in Figure 2, a CE can be dual-homed to
 an SP or to two different SPs via diverse access networks.

Augustyn & Serbest Informational [Page 15] RFC 4665 Service Requirements for L2VPNs September 2006

                 +----------------                    +---------------
                 |                                    |
              +------+                            +------+
    +---------|  PE  |                  +---------|  PE  |
    |         |device|                  |         |device| SP network
    |         +------+                  |         +------+
 +------+         |                  +------+         |
 |  CE  |         |                  |  CE  |         +---------------
 |device|         |   SP network     |device|         +---------------
 +------+         |                  +------+         |
    |         +------+                  |         +------+
    |         |  PE  |                  |         |  PE  |
    +---------|device|                  +---------|device| SP network
              +------+                            +------+
                  |                                   |
                  +----------------                   +---------------
                 (a)                                 (b)
              Figure 2.  Dual-Homed Access of CE Devices
 Resiliency of the L2VPN service can be further enhanced as shown in
 Figure 3, where CE's connected via a "back door" connection, connect
 to the same SP or to different SPs.
                  +----------------                  +---------------
                  |                                  |
 +------+     +------+               +------+     +------+
 |  CE  |-----|  PE  |               |  CE  |-----|  PE  |
 |device|     |device|               |device|     |device| SP network
 +------+     +------+               +------+     +------+
    |             |                     |             |
    | Backdoor    |                     | Backdoor    +---------------
    | link        |   SP network        | link        +---------------
    |             |                     |             |
 +------+     +------+               +------+     +------+
 |  CE  |     |  PE  |               |  CE  |     |  PE  |
 |device|-----|device|               |device|-----|device| SP network
 +------+     +------+               +------+     +------+
                  |                                   |
                  +----------------                   +---------------
                 (a)                                  (b)
             Figure 3.  Backdoor Links Between CE Devices
 Arbitrary combinations of the above methods, with a few examples
 shown in Figure 4, SHOULD be supported by any L2VPN solution.

Augustyn & Serbest Informational [Page 16] RFC 4665 Service Requirements for L2VPNs September 2006

                  +----------------                   +---------------
                  |                                   |
 +------+     +------+               +------+     +------+
 |  CE  |-----|  PE  |               |  CE  |-----|  PE  |
 |device|     |device|               |device|     |device| SP network
 +------+\    +------+               +------+\    +------+
    |     \       |                     |     \       |
    |Back  \      |                     |Back  \      +-------------
    |door   \     |   SP network        |door   \     +-------------
    |link    \    |                     |link    \    |
 +------+     +------+               +------+     +------+
 |  CE  |     |  PE  |               |  CE  |     |  PE  |
 |device|-----|device|               |device|-----|device| SP network
 +------+     +------+               +------+     +------+
                  |                                   |
                  +----------------                   +---------------
                 (a)                                 (b)
              Figure 4.  Combination of Dual-Homing and
                         Backdoor Links for CE Devices

6.7. Customer Traffic

6.7.1. Unicast, Unknown Unicast, Multicast, and Broadcast forwarding

 A VPLS MUST deliver every packet at least to its intended
 destination(s) within the scope of the VPLS, subject to the ingress
 policing and security policies.

6.7.2. Packet Re-ordering

 During normal operation, the queuing and forwarding policies SHOULD
 preserve packet order for packets with the same QoS parameters.

6.7.3. Minimum MTU

 A VPLS MUST support the theoretical MTU of the offered service.
 The committed minimum MTU size MUST be the same for a given VPLS
 instance.  Different L2VPN services MAY have different committed MTU
 sizes.  If the customer VLANs are used as service delimiters, all
 VLANs within a given VPLS MUST inherit the same MTU size.
 A VPLS MAY use IP fragmentation if it presents reassembled packets at
 VPLS customer edge devices.

Augustyn & Serbest Informational [Page 17] RFC 4665 Service Requirements for L2VPNs September 2006

6.7.4. End-point VLAN Tag Translation

 The L2VPN service MAY support translation of customers' AC
 identifiers (e.g., VLAN tags, if the customer VLANs are used as
 service delimiters).  Such service simplifies connectivity of sites
 that want to keep their AC assignments or sites that belong to
 different administrative domains.  In the latter case, the
 connectivity is sometimes referred to as Layer 2 extranet.  On the
 other hand, it should be noted that VLAN tag translation affects the
 support for multiple spanning trees (i.e., 802.1s [IEEE_802.1s]) and
 can break the proper operation.

6.7.5. Transparency

 The L2VPN service is intended to be transparent to Layer 2 customer
 networks.  An L2VPN solution SHOULD NOT require any special packet
 processing by the end users before sending packets to the provider's
 network.
 If VLAN Ids are assigned by the SP, then VLANs are not transparent.
 Transparency does not apply in this case, as it is the same as FR/ATM
 service model.
 Since the IPLS solution aims at transporting encapsulated traffic
 (rather than Layer 2 frames themselves), the IPLS solution MUST not
 alter the packets encapsulated inside Layer 2 frames that are
 transported by the IPLS.  However, the IPLS solution is NOT REQUIRED
 to preserve the Layer 2 header transparently from CE to CE.  For
 example, Source MAC address might not be preserved by the IPLS
 solution.  The IPLS solution MAY remove Layer 2 headers for transport
 over the backbone when those can be reconstructed on egress without
 compromising transport of encapsulated traffic.

6.8. Support for Layer 2 Control Protocols

 The L2VPN solution SHOULD allow transparent operation of Layer 2
 control protocols employed by customers.
 In case of VPLS, the L2VPN service MUST ensure that loops be
 prevented.  This can be accomplished with a loop-free topology or
 appropriate forwarding rules.  Control protocols such as Spanning
 Tree (STP) or similar protocols could be employed.  The L2VPN
 solution MAY use indications from customer Layer 2 control protocols,
 e.g., STP BPDU snooping, to improve the operation of a VPLS.

Augustyn & Serbest Informational [Page 18] RFC 4665 Service Requirements for L2VPNs September 2006

6.9. CE Provisioning

 The L2VPN solution MUST require only minimal or no configuration on
 the CE devices, depending on the type of CE device that connects into
 the infrastructure.

7. Service Provider Network Requirements

 This section describes requirements from an SP perspective.

7.1. Scalability

 This section contains projections regarding L2VPN sizing and
 scalability requirements and metrics specific to particular
 solutions.

7.1.1. Service Provider Capacity Sizing Projections

 [RFC3809] lists projections regarding L2VPN sizing and scalability
 requirements and metrics.  The examples are provided in [RFC3809].

7.1.2. Solution-Specific Metrics

 Each L2VPN solution SHALL document its scalability characteristics in
 quantitative terms.

7.2. Identifiers

 An SP domain MUST be uniquely identified at least within the set of
 all interconnected SP networks when supporting an L2VPN that spans
 multiple SPs.  Ideally, this identifier SHOULD be globally unique
 (e.g., an AS number).
 An identifier for each L2VPN SHOULD be unique, at least within each
 SP's network, as it MAY be used in auto-discovery, management (e.g.,
 alarm and service correlation, troubleshooting, performance
 statistics collection), and signaling.  Ideally, the L2VPN identifier
 SHOULD be globally unique to support the case, where an L2VPN spans
 multiple SPs (e.g., [RFC2685]).  Globally unique identifiers
 facilitate the support of inter-AS/SP L2VPNs.

7.3. Discovering L2VPN Related Information

 Configuration of PE devices (i.e., U-PE and N-PE [RFC4664]) is a
 significant task for an SP.  Solutions SHOULD provide methods that
 dynamically allow L2VPN information to be discovered by the PEs to
 minimize the configuration steps.

Augustyn & Serbest Informational [Page 19] RFC 4665 Service Requirements for L2VPNs September 2006

 Each device in an L2VPN SHOULD be able to determine which other
 devices belong to the same L2VPN.  Such a membership discovery scheme
 MUST prevent unauthorized access, and it allows authentication of the
 source.
 Distribution of L2VPN information SHOULD be limited to those devices
 involved in that L2VPN.  An L2VPN solution SHOULD employ discovery
 mechanisms to minimize the amount of operational information
 maintained by the SPs.  For example, if an SP adds or removes a
 customer port on a given PE, the remaining PEs SHOULD determine the
 necessary actions to take without the SP's having to explicitly
 reconfigure those PEs.
 A L2VPN solution SHOULD support the means for attached CEs to
 authenticate each other and to verify that the SP L2VPN is correctly
 connected.
 The mechanism SHOULD respond to L2VPN membership changes in a timely
 manner.  A "timely manner" is no longer than the provisioning
 timeframe, typically on the order of minutes, and MAY be as short as
 the timeframe required for "rerouting," typically on the order of
 seconds.
 Dynamically creating, changing, and managing multiple L2VPN
 assignments to sites and/or customers is another aspect of membership
 that MUST be addressed in an L2VPN solution.

7.4. Quality of Service (QoS)

 A significant aspect of a provider-provisioned VPN is support for
 QoS.  An SP has control over the provisioning of resources and
 configuration of parameters in at least the PE and P devices, and in
 some cases the CE devices as well.  Therefore, the SP is to provide
 either managed QoS access service, or edge-to-edge QoS service, as
 defined in [RFC4031].

7.5. Isolation of Traffic and Forwarding Information

 From a high level SP perspective, an L2VPN MUST isolate the exchange
 of traffic and forwarding information to only those sites that are
 authenticated and authorized members of an L2VPN.
 An L2VPN solution SHOULD provide a means for meeting provider-
 provisioned VPN QoS SLS requirements that isolates L2VPN traffic from
 the affects of traffic offered by non-VPN customers.  Also, L2VPN
 solutions SHOULD provide a means so that traffic congestion produced
 by sites as part of one L2VPN does not affect another L2VPN.

Augustyn & Serbest Informational [Page 20] RFC 4665 Service Requirements for L2VPNs September 2006

7.6. Security

 The security requirements are stated in Section 6.5.  The security
 requirements provided in [RFC3809] SHOULD be met.  The security
 requirements, except Layer 3 and higher-layer dependent ones,
 specified in [RFC4031], SHOULD be met.
 In addition, an SP network MUST be protected against malformed or
 maliciously constructed customer traffic.  This includes but is not
 limited to duplicate or invalid Layer 2 addresses, customer side
 loops, short/long packets, spoofed management packets, spoofed VLAN
 tags, high volume traffic.
 The SP network devices MUST NOT be accessible from any L2VPN, unless
 specifically authorized.  The devices in the SP network SHOULD
 provide some means of reporting intrusion attempts to the SP, if the
 intrusion is detected.
 When an L2VPN solution operates over a part of the Internet, it
 should support a configurable option to support one or more of the
 following standard IPsec methods for securing a customer's VPN
 traffic:
  1. Confidentiality, so that only authorized devices can decrypt it
  1. Integrity, to ensure that the data has not been altered
  1. Authentication, to ensure that the sender is indeed who he or she

claims to be

  1. Replay attack prevention.
 The above functions SHOULD be applicable to "data traffic" of the
 customer, which includes the traffic exchanged between sites.  It
 SHOULD also be possible to apply these functions to "control
 traffic", such as routing or signaling protocol exchanges, that is
 not necessarily perceived by the customer but is nevertheless
 essential to maintain his or her VPN.
 Furthermore, such security methods MUST be configurable between
 different end-points, such as PE-PE and PE-MTU, only in the case
 where L2VPN data traffic is carried over IP [RFC4023].  Methods to
 secure data flows at the native service layer (Layer-2), from CE-CE,
 CE-MTU and CE-PE, are outside the scope of this document.  It is also
 desirable to configure security on a per-VPN basis.

Augustyn & Serbest Informational [Page 21] RFC 4665 Service Requirements for L2VPNs September 2006

 A VPN solution MAY support one or more encryption schemes, including
 AES, and 3DES.  Encryption, decryption, and key management SHOULD be
 included in profiles as part of the security management system.

7.7. Inter-AS/SP L2VPNs

 All applicable SP requirements, such as traffic and forwarding
 information isolation, SLSes, management, security, provisioning,
 etc.  MUST be preserved across adjacent ASes.  The solution MUST
 describe the inter-SP network interface, encapsulation method(s),
 routing protocol(s), and all applicable parameters.
 An L2VPN solution MUST provide the specifics of offering L2VPN
 services spanning multiple ASes and/or SPs.
 An L2VPN solution MUST support proper dissemination of operational
 parameters to all elements of an L2VPN service in the presence of
 multiple ASes and/or SPs.  A L2VPN solution MUST employ mechanisms
 for sharing operational parameters between different ASes.
 An L2VPN solution SHOULD support policies for proper selection of
 operational parameters coming from different ASes.  Similarly, an
 L2VPN solution SHOULD support policies for selecting information to
 be disseminated to different ASes.

7.7.1. Management

 The general requirements for managing a single AS apply to a
 concatenation of ASes.  A minimum subset of such capabilities is the
 following:
  1. Diagnostic tools
  1. Secured access to one AS management system by another
  1. Configuration request and status query tools
  1. Fault notification and trouble tracking tools

7.7.2. Bandwidth and QoS Brokering

 When an L2VPN spans multiple ASes, there is a need for a brokering
 mechanism that requests certain SLS parameters, such as bandwidth and
 QoS, from the other domains and/or networks involved in transferring
 traffic to various sites.  The essential requirement is that a
 solution MUST be able to determine whether a set of ASes can
 establish and guarantee uniform QoS in support of a provider-
 provisioned VPN.

Augustyn & Serbest Informational [Page 22] RFC 4665 Service Requirements for L2VPNs September 2006

7.8. L2VPN Wholesale

 The architecture MUST support the possibility of one SP's 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.

7.9. 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:
  1. Relevant identifiers
  1. QoS/SLS parameters
  1. Restoration parameters
  1. Multiplexing identifiers
  1. Security parameters
 There MUST be a means to monitor the following aspects of tunnels:
  1. Statistics, such as amount of time spent in the up and down state
  1. Count of transitions between the up and down state
  1. 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.

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

Augustyn & Serbest Informational [Page 23] RFC 4665 Service Requirements for L2VPNs September 2006

 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.

7.11. Backbone Networks

 Ideally, the backbone interconnecting the 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 SLSes for VPN
 service offerings.

7.12. 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
 an L2VPN service instance.  The solution SHOULD guarantee
 availability of resources necessary to fulfill the obligation of
 committed SLSes.

7.13. Interoperability

 Service providers are interested in interoperability in at least the
 following scenarios:
  1. To facilitate use of PE and managed CE devices within a single SP

network

Augustyn & Serbest Informational [Page 24] RFC 4665 Service Requirements for L2VPNs September 2006

  1. To implement L2VPN services across two or more interconnected SP

networks

  1. To achieve inter-working or interconnection between customer sites

using different L2VPN solutions or different implementations of the

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

7.14. 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:
  1. Checking connectivity between "service-aware" network nodes
  1. Verifying data plane and control plane integrity
  1. 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.

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

Augustyn & Serbest Informational [Page 25] RFC 4665 Service Requirements for L2VPNs September 2006

8. Service Provider Management Requirements

 An 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 MIB Modules), 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].

9. Engineering Requirements

 These requirements are driven by implementation characteristics that
 make service and SP requirements achievable.

9.1. Control Plane Requirements

 An L2VPN service 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 service.  A
 mechanism for isolating the distribution of reachability information
 to only those sites associated with an 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 an L2VPN
 service grows.
 An 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 an L2VPN service.

Augustyn & Serbest Informational [Page 26] RFC 4665 Service Requirements for L2VPNs September 2006

9.2. Data Plane Requirements

9.2.1. Encapsulation

 An L2VPN solution SHOULD utilize the encapsulation techniques defined
 by PWE3 ([RFC3985]), and SHOULD not impose any new requirements on
 these techniques.

9.2.2. Responsiveness to Congestion

 An L2VPN solution SHOULD utilize the congestion avoidance techniques
 defined by PWE3 ([RFC3985]).

9.2.3. Broadcast Domain

 A separate Broadcast Domain MUST be maintained for each VPLS.
 In addition to VPLS Broadcast Domains, an 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.

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

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

Augustyn & Serbest Informational [Page 27] RFC 4665 Service Requirements for L2VPNs September 2006

10. 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 6.5.  Further details on security
 requirements are given from the customer and service provider
 perspectives in Sections 6.5 and 7.6, respectively.  In an analogous
 manner, further detail on traffic and routing isolation requirements
 are given from the customer and service provider perspectives in
 Sections 5.4 and 7.5, respectively.  Safeguards to protect network
 resources such as CPU, memory, and bandwidth are required in Section
 7.12.
 IPsec can also be applied after tunneling Layer 2 traffic to provide
 additional security.
 In the case where an L2VPN service is carried over IP [RFC4023],
 traverses multiple SP networks and passes through an unsecured SP,
 POP, NAP, or IX, then security mechanisms MUST be employed.  These
 security mechanisms include encryption, authentication, and resource
 protection, as described in section 5.5.  For example, a provider
 should consider using both authentication and encryption for a tunnel
 used as part of an L2VPN that traverses another service provider's
 network.

11. Acknowledgements

 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 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 the Layer 3 VPN requirements design team.

Augustyn & Serbest Informational [Page 28] RFC 4665 Service Requirements for L2VPNs September 2006

12. References

12.1. Normative References

 [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC4026]       Andersson, L. and T. Madsen, "Provider Provisioned
                 Virtual Private Network (VPN) Terminology", RFC 4026,
                 March 2005.

12.2. Informative References

 [VPLS_LDP]      Lasserre, M., Kompella, V. "Virtual Private LAN
                 Services over MPLS", Work in Progress.
 [VPLS_BGP]      Kompella, K., Rekhter, Y. "Virtual Private LAN
                 Service", Work in Progress.
 [IPLS]          Shah, H., et al. "IP-Only LAN Service (IPLS)", Work
                 in Progress.
 [IEEE_802.1Q]   IEEE Std 802.1Q-1998, "Virtual Bridged Local Area
                 Networks", 1998
 [RFC2205]       Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
                 Jamin, "Resource ReSerVation Protocol (RSVP) --
                 Version 1 Functional Specification", RFC 2205,
                 September 1997.
 [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.
 [RFC2685]       Fox, B. and B. Gleeson, "Virtual Private Networks
                 Identifier", RFC 2685, September 1999.
 [RFC3270]       Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
                 Vaananen, P., Krishnan, R., Cheval, P., and J.
                 Heinanen, "Multi-Protocol Label Switching (MPLS)
                 Support of Differentiated Services", RFC 3270, May
                 2002.
 [RFC3308]       Calhoun, P., Luo, W., McPherson, D., and K. Peirce,
                 "Layer Two Tunneling Protocol (L2TP) Differentiated
                 Services Extension", RFC 3308, November 2002.

Augustyn & Serbest Informational [Page 29] RFC 4665 Service Requirements for L2VPNs September 2006

 [RFC3809]       Nagarajan, A., "Generic Requirements for Provider
                 Provisioned Virtual Private Networks (PPVPN)", RFC
                 3809, June 2004.
 [RFC3985]       Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
                 to-Edge (PWE3) Architecture", RFC 3985, March 2005.
 [RFC4023]       Worster, T., Rekhter, Y., and E. Rosen,
                 "Encapsulating MPLS in IP or Generic Routing
                 Encapsulation (GRE)", RFC 4023, March 2005.
 [RFC4031]       Carugi, M. and D. McDysan, "Service Requirements for
                 Layer 3 Provider Provisioned Virtual Private Networks
                 (PPVPNs)", RFC 4031, April 2005.
 [RFC4664]       Andersson, L. and E. Rosen, "Framework for Layer 2
                 Virtual Private Networks (L2VPNs)", RFC 4664,
                 September 2006.
 [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.
 [ITU_Y.1311.1]  Carugi, M. (editor), "Network Based IP VPN over MPLS
                 architecture",Y.1311.1 ITU-T Recommendation, May
                 2001.
 [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.1AE]  IEEE 802.1AE/D5.1, "Draft Standard for Local and
                 Metropolitan Area Networks - Media Access Control
                 (MAC) Security", P802.1AE/D5.1, January 19, 2006.
 [IEEE_802.1s]   IEEE Std 802.1s-2002, "Virtual Bridged Local Area
                 Networks-Amendment 3: Multiple Spanning Trees", 2002.

Augustyn & Serbest Informational [Page 30] RFC 4665 Service Requirements for L2VPNs September 2006

Editors' Addresses

 Waldemar Augustyn
 EMail: waldemar@wdmsys.com
 Yetik Serbest
 AT&T Labs
 9505 Arboretum Blvd.
 Austin, TX 78759
 EMail: yetik_serbest@labs.att.com

Augustyn & Serbest Informational [Page 31] RFC 4665 Service Requirements for L2VPNs September 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Augustyn & Serbest Informational [Page 32]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4665.txt · Last modified: 2006/09/18 23:46 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki