doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc4665.txt b/doc/rfc/rfc4665.txt
new file mode 100644
index 0000000..39b82ac
--- /dev/null
+++ b/doc/rfc/rfc4665.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+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:
+
+   - The reliability may likely be less, i.e., the probability that a
+     message broadcast over the VPLS is not seen by one of the bridge
+     modules in PEs is higher than in a true Ethernet.
+
+   - VPLS frames can get duplicated if the PW sequencing option isn't
+     turned on.  The data frames on the PWs are sent in IP datagrams,
+     and under certain failure scenarios, IP networks can duplicate
+     packets.  If the PW data transmission protocol does not ensure
+     sequence of data packets, frames can be duplicated or received out
+     of sequence.  If the customer's Bridge Protocol Data Unit (BPDU)
+     frames are sent as data packets, then BPDU frames can be duplicated
+     or mis-sequenced, although this may not create any problems for
+     Real-Time Streaming Protocol (RSTP).
+
+   - Delayed delivery of packets (e.g., more than half a second), rather
+     than dropping them, could have adverse effect on the performance of
+     the service.
+
+   - 802.3x Pause frames will not be transported over a VPLS, as the
+     bridge module ([RFC4664]) in the PE terminates them.
+
+   - Since the IPLS solution aims at transporting encapsulated traffic
+     (rather than Layer 2 frames themselves), the IPLS solution is NOT
+     REQUIRED to preserve the Layer 2 Header transparently from CE to
+     CE.  For example, Source MAC address will probably not be preserved
+     by the IPLS solution.
+
+5.2.  Traffic Types
+
+   A VPLS MUST support unicast, multicast, and broadcast traffic.
+   Support for efficient replication of broadcast and multicast traffic
+   is highly desirable.
+
+5.3.  Topology
+
+   A SP network may be realized using one or more network tunnel
+   topologies to interconnect PEs, ranging from simple point-to-point to
+   distributed hierarchical arrangements.  The typical topologies
+   include:
+
+
+
+Augustyn & Serbest           Informational                      [Page 8]
+
+RFC 4665            Service Requirements for L2VPNs       September 2006
+
+
+      - Point-to-point
+      - Point-to-multipoint, a.k.a. hub and spoke
+      - Any-to-any, a.k.a. full mesh
+      - Mixed, a.k.a. partial mesh
+      - Hierarchical
+
+   Regardless of the SP topology employed, the service to the customers
+   MUST retain the connectivity type implied by the type of L2VPN.  For
+   example, a VPLS MUST allow multipoint-to-multipoint connectivity even
+   if it is implemented with point-to-point circuits.  This requirement
+   does not imply that all traffic characteristics (such as bandwidth,
+   QoS, delay, etc.) necessarily be the same between any two end points
+   of an L2VPN.  It is important to note that SLS requirements of a
+   service have a bearing on the type of topology that can be used.
+
+   To the extent possible, an L2VPN service SHOULD be capable of
+   crossing multiple administrative boundaries.
+
+   To the extent possible, the L2VPN services SHOULD be independent of
+   access network technology.
+
+5.4.  Isolated Exchange of Data and Forwarding Information
+
+   L2VPN solutions SHALL define means that prevent CEs in an L2VPN from
+   interaction with unauthorized entities.
+
+   L2VPN solutions SHALL avoid introducing undesired forwarding
+   information that could corrupt the L2VPN forwarding information base.
+
+   A means to constrain or isolate the distribution of addressed data to
+   only those VPLS sites determined either by MAC learning and/or
+   configuration MUST be provided.
+
+   The internal structure of an L2VPN SHOULD not be advertised or
+   discoverable from outside that L2VPN.
+
+5.5.  Security
+
+   A range of security features MUST be supported by the suite of L2VPN
+   solutions.  Each L2VPN solution MUST state which security features it
+   supports and how such features can be configured on a per-customer
+   basis.
+
+   A number of security concerns arise in the setup and operation of an
+   L2VPN, ranging from misconfigurations to attacks that can be launched
+   on an L2VPN and can strain network resources such as memory space,
+   forwarding information base table, bandwidth, and CPU processing.
+
+
+
+
+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.
+
+   - Protocol attacks
+     o Excessive protocol adjacency setup/teardown
+     o Excessive protocol signaling/withdrawal
+
+   - Resource Utilization
+     o Forwarding plane replication (VPLS)
+     o Looping (VPLS primarily)
+     o MAC learning table size limit (VPLS)
+
+   - Unauthorized access
+     o Unauthorized member of VPN
+     o Incorrect customer interface
+     o Incorrect service delimiting VLAN tag
+     o Unauthorized access to PE
+
+   - Tampering with signaling
+     o Incorrect FEC signaling
+     o Incorrect PW label assignment
+     o Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.)
+
+   - Tampering with data forwarding
+     o Incorrect MAC learning entry
+     o Incorrect PW label
+     o Incorrect AC identifier
+     o Incorrect customer facing encapsulation
+     o Incorrect PW encapsulation
+     o Hijacking PWs using the wrong tunnel
+     o Incorrect tunnel encapsulation
+
+5.5.1.  User Data Security
+
+   An L2VPN solution MUST provide traffic separation between different
+   L2VPNs.
+
+   In case of VPLS, VLAN Ids MAY be used as service delimiters.  When
+   used in this manner, they MUST be honored and traffic separation MUST
+   be provided.
+
+5.5.2.  Access Control
+
+   An L2VPN solution MAY also have the ability to activate the
+   appropriate filtering capabilities upon request of a customer.
+
+
+
+
+
+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:
+
+   - Best Effort  (support mandatory for all provider-provisioned
+                  VPN types)
+
+   - Aggregate CE Interface Level QoS (i.e., 'hose' level)
+
+   - Site-to-site, or 'pipe' level QoS
+
+   Note that all cases involving QoS MAY require that the CE and/or PE
+   perform shaping and/or policing.
+
+   Mappings or translations of Layer 2 QoS parameters into PSN QoS
+   (e.g., DSCPs or MPLS EXP field) as well as QoS mapping based on VC
+   (e.g., FR/ATM or VLAN) MAY be performed in order to provide QoS
+   transparency.  The actual mechanisms for these mappings or
+   translations are outside the scope of this document.  In addition,
+   the Diffserv support of underlying tunneling technologies (e.g.,
+   [RFC3270] or [RFC3308]) and the Intserv model ([RFC2205]) MAY be
+   used.  As such, the L2VPN SLS requirements SHOULD be supported by
+   appropriate core mechanisms.
+
+5.7.2.  Service Models
+
+   A service provider may desire to offer QoS service to a customer for
+   at least the following generic service types: managed access VPN
+   service or an edge-to-edge QoS service.  The details of the service
+   models can be found in [RFC3809] and in [RFC4031].
+
+   In L2VPN service, both DSCP ([RFC2474]) and 802.1p ([IEEE_802.1D])
+   fields may be used for this purpose.
+
+
+
+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
+
+   - direct physical links (e.g., 100BaseTX, and T1/E1 TDM),
+   - logical links (e.g., ATM PVC, and RFC2427-encapsulated link),
+   - transport networks carrying Ethernet,
+   - 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:
+
+   - Confidentiality, so that only authorized devices can decrypt it
+
+   - Integrity, to ensure that the data has not been altered
+
+   - Authentication, to ensure that the sender is indeed who he or she
+     claims to be
+
+   - 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:
+
+   - Diagnostic tools
+
+   - Secured access to one AS management system by another
+
+   - Configuration request and status query tools
+
+   - 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:
+
+   - Relevant identifiers
+
+   - QoS/SLS parameters
+
+   - Restoration parameters
+
+   - Multiplexing identifiers
+
+   - Security parameters
+
+   There MUST be a means to monitor the following aspects of tunnels:
+
+   - Statistics, such as amount of time spent in the up and down state
+
+   - Count of transitions between the up and down state
+
+   - Events, such as transitions between the up and down states
+
+   The tunneling technology used by the VPN SP and its associated
+   mechanisms for tunnel establishment, multiplexing, and maintenance
+   MUST meet the requirements on scaling, isolation, security, QoS,
+   manageability, etc.
+
+   Regardless of the tunneling choice, the existence of the tunnels and
+   their operations MUST be transparent to the customers.
+
+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:
+
+   - 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
+
+
+   - To implement L2VPN services across two or more interconnected SP
+     networks
+
+   - To achieve inter-working or interconnection between customer sites
+     using different L2VPN solutions or different implementations of the
+     same approach
+
+   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:
+
+   - Checking connectivity between "service-aware" network nodes
+
+   - Verifying data plane and control plane integrity
+
+   - Verifying service membership
+
+   The provided mechanisms MUST satisfy the following: the connectivity
+   checking for a given customer MUST enable the end-to-end testing of
+   the data path used by that of customer's data packets, and the test
+   packets MUST not propagate beyond the boundary of the SP network.
+
+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]
+