返回首页

RFC 4665 - Service Requirements for Layer 2 Provider-Provisi

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroupW.Augustyn,Ed. RequestforComments:4665Y.Serbest,Ed. Category:Informational ATT September2006 ServiceRequirementsforLayer2 Provider-ProvisionedVirtualPrivateNetworks StatusofThisMemo ThismemoprovidesinformationfortheInternetcommunit
  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.

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

           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

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

   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.

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.

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.

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:

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

   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.

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.

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
------分隔线----------------------------
顶一下
(1)
100%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容