[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 rfc4664                                     
Network Working Group                                      Loa Andersson
Internet Draft
Expiration Date: March 2004                                Eric C. Rosen
                                                     Cisco Systems, Inc.


                                                          September 2003

                            L2VPN Framework


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

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


   This document provides a framework for Layer 2 Provider Provisioned
   Virtual Private Networks (PPVPNs). This framework is intended to aid
   in standardizing protocols and mechanisms to support interoperable
   Layer 2 PPVPNs.

Andersson, et al.                                               [Page 1]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

Table of Contents

    1          Introduction  .......................................   3
    1.1        Conventions used in this document  ..................   3
    1.2        Objectives and Scope of the Document  ...............   3
    1.3        Layer 2 Virtual Private Networks  ...................   4
    1.4        Terminology  ........................................   5
    2          Models  .............................................   5
    2.1        Reference Model for VPWS  ...........................   5
    2.1.1      Entities in the VPWS reference model  ...............   5
    2.2        Reference Model for VPLS  ...........................   6
    2.2.1      Entities in the VPLS reference model  ...............   8
    2.3        Reference Model for Distributed VPLS-PE or VPWS-PE  .   9
    2.3.1      Entities in the Distributed PE Reference Models  ....   9
    2.4        VPWS-PE and VPLS-PE  ................................   9
    3          Functional Components of L2 VPN  ....................   9
    3.1        Types of L2VPN  .....................................  10
    3.1.1      Virtual Private Wire Service (VPWS)  ................  10
    3.1.2      Virtual Private LAN Service (VPLS)  .................  10
    3.1.3      IP-only LAN-like Service (IPLS)  ....................  11
    3.2        Generic L2VPN Transport Functional Components  ......  11
    3.2.1      Attachment Circuits  ................................  12
    3.2.2      Pseudowires  ........................................  12
    3.2.3      Forwarders  .........................................  13
    3.2.4      Tunnels  ............................................  15
    3.2.5      Encapsulation  ......................................  15
    3.2.6      Pseudowire Signaling  ...............................  16    Point-to-Point Signaling  ...........................  17    Point-to-Multipoint Signaling  ......................  18    Inter-AS Considerations  ............................  19
    3.2.7      Service Quality  ....................................  20    Quality of Service (QoS)  ...........................  20    Resiliency  .........................................  21
    3.2.8      Management  .........................................  22
    3.3        VPWS  ...............................................  22
    3.3.1      Provisioning and Auto-Discovery  ....................  23    Attachment Circuit Provisioning  ....................  23    PW Provisioning for Arbitrary Overlay Topologies  ...  23    Colored Pools PW Provisioning Model  ................  25
    3.3.2      Requirements on Auto-Discovery Procedures  ..........  27
    3.3.3      Heterogeneous Pseudowires  ..........................  28
    3.4        VPLS Emulated LANs  .................................  29
    3.4.1      VPLS Overlay Topologies and Forwarding  .............  31
    3.4.2      Provisioning and Auto-Discovery  ....................  33
    3.4.3      Distributed PE  .....................................  33
    3.4.4      Scaling issues in VPLS deployment  ..................  36

Andersson, et al.                                               [Page 2]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

    3.5        IP-only LAN-like Service (IPLS)  ....................  36
    4          Security Considerations  ............................  37
    4.1        Provider Network Security Issues  ...................  37
    4.2        Provider-Customer Network Security Issues  ..........  38
    4.3        Customer Network Security Issues  ...................  39
    5          Intellectual Property Notice  .......................  40
    6          Copyright Notice  ...................................  40
    7          Normative References  ...............................  41
    8          Informative References  .............................  41
    9          Authors and Acknowledgments  ........................  42
   10          Authors' Contact Information  .......................  43

1. Introduction

1.1. Conventions used in this document

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

1.2. Objectives and Scope of the Document

   This document provides a framework for Layer 2 Provider Provisioned
   Virtual Private Networks (PPVPNs).  This framework is intended to aid
   in standardizing protocols and mechanisms to support interoperable
   Layer2 PPVPNs.

   The PPVPN WG group works with both Layer 3 PPVPNs and Layer 2 PPVPNs.
   A framework for L3 VPNs is found in [L3VPN-FW]. This document
   provides the same type of framework for Layer 2 PPVPNs as the Layer 3
   framework does for Layer 3 PPVPNs.

   The term "provider provisioned VPNs" refers to Virtual Private
   Networks (VPNs) for which the Service Provider (SP) participates in
   management and provisioning of the VPN.

   There are multiple ways in which a provider can participate in a VPN,
   and there are therefore multiple different types of PPVPNs.  The
   framework document discusses Layer2 VPNs (as defined in section 1.3).
   It also describes technical issues related to VPNs in which the
   provider participates in provisioning for provider edge and customer
   edge devices.

Andersson, et al.                                               [Page 3]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   First, this document discusses reference models for Layer 2 PPVPNs.
   Then the functional components of Layer2 PPVPN operations are

   Specifically, this includes discussion of the technical issues, which
   are important in the design of standards and mechanisms for support
   of Layer 2 PPVPNs.  Furthermore, technical aspects of Layer2 PPVPNs
   interworking is clarified.  Finally, security issues as they apply to
   Layer2 PPVPNs are addressed.

   Requirements for Layer 3 VPNs are found in [L3VPN-REQ] and for Layer
   2 VPNs, for VPLS and VPWS, in [L2VPN-REQ].

   This document does not make choices, and does not select any
   particular approach to support VPNs.

1.3. Layer 2 Virtual Private Networks

   As Layer 2 provider provisioned VPN solutions has attracted more and
   more interest, several solutions has been proposed to the PPVPN WG.
   This document addresses the generic components relevant for every
   Layer 2 VPN but will not make any recommendations on the relative
   merits of how the different components are implemented.

   We see two kinds of services that a service provider could offer to a
   customer by means of Layer 2 VPNs. Virtual Private Wire Service
   (VPWS)and a Virtual Private LAN Service (VPLS). The possibility of an
   IP-only LAN-like Service (IPLS, [IPLS]) is opened up as well.

   A VPWS is a VPN service that supplies a L2 point-to-point service.
   Being a point-to-point service where there are very few scaling
   issues with the service as such. Scaling issues might arise from the
   number of end- points that can be supported on a particular PE.

   A VPLS is an L2 service that in all respects emulates LAN across a
   Wide Area Network (WAN). Thus it also has all the scaling
   characteristics of a LAN. Other scaling issues might arise from the
   number of end-points that can be supported on a particular PE.

Andersson, et al.                                               [Page 4]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

1.4. Terminology

   This document list some terms and concepts that are specific to the
   L2 VPN framework, terms and concepts generally applicable to the
   PPVPN area will be found in [L2VPN-TERM].

2. Models

2.1. Reference Model for VPWS

   The VPWS reference model is shown in Figure 1.

                  Attachment        PSN           Attachment
                   Circuits        tunnel          Circuits
           +-----+                 pseudo                    +-----+
           |     |                  wire                     |     |
           | CE1 |--+                                     +--| CE2 |
           |     |  |    +-----+   +-----+     +-----+    |  |     |
           +-----+  +----|---- |   |  P  |     | ----+----+  +-----+
                         | PE1 |===|=====|=====| PE2 |
                         |    /|---|-----|-----|\    |
           +-----+  +----|---- |   |     |     | ----|----+  +-----+
           |     |  |    +-----+   +-----+     +-----+    |  |     |
           | CE3 |--+                                     +--| CE4 |
           |     |                                           |     |
           +-----+                                           +-----+

                              Figure 1

2.1.1. Entities in the VPWS reference model

   The P, PE (VPWS-PE) and CE devices and the PSN tunnel as defined in
   [L2VPN-TERM]. Attachment circuit and pseudo wire as discussed in
   section 3. The PE does a simple mapping between the PW and attachment
   circuit based on local information, i.e. the PW de-multiplexor and
   incoming/outgoing logical/physical port.

Andersson, et al.                                               [Page 5]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

2.2. Reference Model for VPLS

   The following diagram shows a VPLS reference model where PE devices
   that are VPLS-capable provide a logical interconnect such that CE
   devices belonging to a specific VPLS appear to be on a single bridged
   Ethernet. A VPLS can contain a single VLAN or multiple, tagged VLANs.

   The VPLS reference model is shown in Figures 2 and 3.

          +-----+                                  +-----+
          + CE1 +--+                           +---| CE2 |
          +-----+  |    ...................    |   +-----+
           VPLS A  |  +----+           +----+  |    VPLS A
                   |  |VPLS|           |VPLS|  |
                   +--| PE |--Routed---| PE |-+
                      +----+  Backbone +----+
                     /  .       |         .  \     _   /\_
          +-----+   /   .       |         .   \   / \ /   \     +-----+
          + CE  +--+    .       |         .    +--\ Access \----| CE  |
          +-----+       .    +----+       .       | Network |   +-----+
           VPLS B       .....|VPLS|........        \       /     VPLS B
                             | PE |     ^           -------
                             +----+     |
                               |        |
                               |        |
                            +-----+     |
                            | CE3 |     +-- Emulated LAN
                             VPLS A

                             Figure 2

Andersson, et al.                                               [Page 6]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

                              |-----Routed Backbone------|
                              |     (P Routers)          |PSN Tunnels,
       Emulated LAN           |                          |Pseudowires
     .                        |                          |                   .
     . |----------------------|----|           |---------|-----------------| .
     . |  --------------------|--- |           |  -------|---------------- | .
     . |       VPLS Forwarder      |           |       VPLS Forwarder      | .
     . |  ----------|------------- |           |  ----------|------------- | .
       |            | Emulated LAN |           |            | Emulated LAN |
       |            | Interface    | VPLS-PEs  |            | Interface    |
       |            |              |  <---->   |            |              |
       |  ----------|------------  |           |  ----------|------------  |
       |  |       Bridge        |  |           |  |       Bridge        |  |
       |  -|--------|---------|--  |           |  ---|-------|---------|-  |
       |---|--------|---------|----|           |-----|-------|---------|---|
           |        |         |                      |       |         |
           |        | Access  |                      |       | Access  |
           |        | Networks|                      |       | Networks|
           |        |         |                      |       |         |
           |        |         |                      |       |         |
                CE devices                                 CE devices
                                 Figure 3

   From Figure 3, we see that in VPLS, a CE device attaches, possibly
   through an access network, to a "bridge" module of a VPLS-PE.  Within
   the VPLS-PE, the bridge module attaches, through an "Emulated LAN
   Interface" to an Emulated LAN.  For each VPLS, there is an Emulated
   LAN instance. Figure 3 shows some internal structure to the Emulated
   LAN: it consists "VPLS Forwarder" modules (one per VPLS-PE per VPLS
   instance) connected by Pseudowires, where the Pseudowires may be
   traveling through PSN tunnels over a routed backbone.

   The functionality which the bridge module must support depends on the
   service which is being offered by the SP to its customers, as well as
   on various details of the SP's network.  At minimum, the bridge
   module must be able to learn MAC addresses, and to "age them out", in
   the standard manner.  However, if the PE devices have backdoor
   connections with each other via a layer 2 network, they may need to
   be full IEEE bridges, running spanning tree with each other.
   Specification of the precise functionality which the bridge modules
   must have in particular circumstances is, however, out of scope of
   the current document.

   This framework specifies that each "bridge module" has a single

Andersson, et al.                                               [Page 7]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   "Emulated LAN interface".  It does not specify the number of bridge
   modules that a VPLS-PE may contain, nor does it specify the number of
   VPLS instances which may attach to a bridge module over a single
   "Emulated LAN interface".

   Thus the framework is compatible with at least the following three

     - Model 1

       A VPLS-PE contains a single bridge module, and supports a single
       VPLS instance.  The VPLS instance is an Emulated LAN; if that
       Emulated LAN contains VLANs, 802.1Q tagging must be used to
       indicate which packets are in which VLANs.

     - Model 2

       A VPLS-PE contains a single bridge module, but supports multiple
       VPLS instances.  Each VPLS instance is thought of as a VLAN (in
       effect, an "Emulated VLAN"), and the set of VPLS instances are
       treated as a set of VLANs on a common LAN.

     - Model 3

       A VPLS-PE contains an arbitrary number of bridge modules, each of
       which attaches to a single VPLS instance.

   There may be other models as well, some of which are combinations of
   the 3 models above.  Different models may have different
   characteristics, and different scopes of applicability.

   Each VPLS solution should specify the model or models that it is
   supporting.  Each solution should also specify the necessary bridge
   functionality that its bridge modules must support.

   This framework does not specify the way in which bridge control
   protocols are used on the Emulated LANs.

2.2.1. Entities in the VPLS reference model

   The PE (VPLS-PE) and CE devices are defined in [L2VPN-TERM].

Andersson, et al.                                               [Page 8]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

2.3. Reference Model for Distributed VPLS-PE or VPWS-PE

                    Functionality       . . . . . . .
                . . . . . . . . . . .   .           .
                .                   .   .           .
        +----+  .  +----+    +----+ .   .  Service  .
        | CE |--.--|U-PE|----|N-PE|-.---.  Provider .
        +----+  .  +----+    +----+ .   .  Backbone .
                . . . . . . . . . . .   .           .

2.3.1. Entities in the Distributed PE Reference Models

   A VPLS-PE or a VPWS-PE functionality may be distributed to more than
   one device. The device closer to the customer/user is called User
   facing PE (U-PE) and the device closer to the core network is called
   Network facing PE (N-PE).

   For further discussion see section 3.4.3.

   The terms "U-PE" and "N-PE" are defined in [L2VPN-TERM].

2.4. VPWS-PE and VPLS-PE

   The VPWS-PE and VPLS-PE are functionally very similar, the they both
   use forwarders to map attachment circuits to pseudo-wires. The only
   differences is that while the forwarder in a VPWS-PE does a one-to-
   one mapping between the attachment circuit and pseudo-wire, the
   forwarder in a VPLS-PE is a Virtual Switching Instance (VSI) that
   maps multiple attachment circuits to multiple pseudo-wires (for
   further discussion see section 3.)

3. Functional Components of L2 VPN

   This section specifies a functional model for L2VPN, which allows one
   to break an L2VPN architecture down into its functional components.
   This allows us to exhibit the roles played by the various protocols
   and mechanisms, and thus to make it easier to understand the
   differences and similarities between various proposed L2VPN

   Section 3.1 contains an overview of some different types of L2VPN.
   In section 3.2, functional components that are common to the

Andersson, et al.                                               [Page 9]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   different types are discussed. Then there is a section for each of
   the L2VPN service types being considered. The latter sections discuss
   functional components, which may be specific to particular L2VPN
   types, as well as discussing type-specific features of the generic

3.1. Types of L2VPN

   The types of L2VPN are distinguished by the characteristics of the
   service that they offer to the customers of the Service Provider

3.1.1. Virtual Private Wire Service (VPWS)

   In a VPWS, each CE device is presented with a set of point-to-point
   virtual circuits.

   The other end of each virtual circuit is another CE device. Frames
   transmitted by a CE on such a virtual circuit are received by the CE
   device at the other end-point of the virtual circuit. Forwarding from
   one CE device to another is not affected by the content of the frame,
   but is fully determined by the virtual circuit on which the frame is
   transmitted. The PE thus acts as a virtual circuit switch.

   This type of L2VPN has long been available over ATM and Frame Relay
   backbones. Providing this type of L2VPN over MPLS and/or IP backbones
   is the current topic.

   Requirements for this type of L2VPN are specified in [L2VPN-REQ].

3.1.2. Virtual Private LAN Service (VPLS)

   In a VPLS, each CE device has one or more LAN interfaces that lead to
   a "virtual backbone".

   Two CEs are connected to the same virtual backbone if and only if
   they are members of the same VPLS instance (i.e., same VPN). When a
   CE transmits a frame, the PE that receives it examines the MAC
   Destination Address field in order to determine how to forward the
   frame. Thus the PE functions as a bridge.  As is indicated in Figure
   3, if a set of PEs support a common VPLS instance, then there is an
   Emulated LAN, corresponding to that VPLS instance, to which each of
   those PE bridges attaches (via an emulated interface). From the
   perspective of a CE device, the virtual backbone is the set of PE
   bridges and the Emulated LAN on which they reside.  Thus to a CE

Andersson, et al.                                              [Page 10]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   device, the LAN which attaches it to the PE is extended transparently
   over the routed MPLS and/or IP backbone.

   The PE bridge function treats the Emulated LAN as it would any other
   LAN to which it has an interface.  Forwarding decisions are made in
   the manner which is normal for bridges, based on MAC Source Address

   VPLS is like VPWS in that forwarding is done without any
   consideration of the Layer3 header. VPLS is unlike VPWS in that:

     - VPLS allows the PE to use addressing information in a frame's L2
       header to determine how to forward the frame;

     - VPLS allows a single CE/PE connection to be used for transmitting
       frames to multiple remote CEs; in this particular respect, VPLS
       resembles L3VPN more than VPWS.

   Requirements for this type of L2VPN are specified in [L2VPN-REQ].

3.1.3. IP-only LAN-like Service (IPLS)

   An IPLS is very like a VPLS, except that:

     - it is assumed that the CE devices are hosts or routers, not

     - it is assumed that the service will only carry IP packets, and
       supporting packets such as ICMP and ARP; Layer2 packets which do
       not contain IP are not supported.

   While this service is a functional subset of the VPLS service, it is
   considered separately because it may be possible to provide it using
   different mechanisms, which may allow it to run on certain hardware
   platforms that cannot support the full VPLS functionality.

3.2. Generic L2VPN Transport Functional Components

   All L2VPN types must transport "frames" across the core network
   connecting the PE's. In all L2VPN types, a PE (PE1) receives a frame
   from a CE (CE1), then transports the frame to a PE (PE2), which then
   transports the frame to a CE (CE2).  In this section, we discuss the
   functional components, which are necessary to transport L2 frames in
   any type of L2VPN service.

Andersson, et al.                                              [Page 11]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

3.2.1. Attachment Circuits

   In any type of L2VPN, a CE device attaches to a PE device via some
   sort of circuit or virtual circuit. We will call this an "Attachment
   Circuit" (AC). We use this term very generally; an Attachment Circuit
   may be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN,
   a PPP connection on a physical interface, a PPP session from an L2TP
   tunnel, an MPLS LSP, etc. The CE device may be a router, a switch, a
   host, or just about anything, which the customer needs hooked up to
   the VPN.  An AC carries a frame between CE and PE, or vice versa.

   Procedures for setting up and maintaining the ACs are out of scope of
   this architecture.

   These procedures are generally specified as part of the specification
   of the particular Attachment Circuit technology.

   Any given frame will traverse an AC from a CE to a PE and then on
   another AC from a PE to a CE.

   We refer to the former AC as the frame's "ingress AC" and to the
   latter AC as the frame's "egress AC".  Note that this notion of
   "ingress AC" and "egress AC" is relative to a specific frame, and
   denotes nothing more than the frame's direction of travel while on
   that AC.

3.2.2. Pseudowires

   A "Pseudowire" (PW) is a relation between two PE devices.  Whereas an
   AC is used to carry a frame from CE to PE, a PW is used to carry a
   frame between two PEs.  We use the term "pseudowire" in the sense of
   [PWE3- ARCH].

   Setting up and maintaining the PWs is the job of the PEs.  State
   information for a particular PW is maintained at the two PEs which
   are its endpoints, but not at other PEs, and not in the backbone
   routers (P routers).

   Pseudowires may be point-to-point, multipoint-to-point, or point-to-
   multipoint. In this framework, point-to-point PWs are always
   considered to be bidirectional; multipoint-to-point and point-to-
   multipoint PWs are always considered to be unidirectional.
   Multipoint-to-point PWs can be used only when the PE receiving a
   frame from the PW does not need to know where the frame came from.
   Point-to-multipoint PWs may be useful when frames need to be

Andersson, et al.                                              [Page 12]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   Procedures for setting up and maintaining point-to-multipoint PWs are
   not considered in this version of this framework.

   Any given frame travels first on its ingress AC, then on a PW, then
   on its egress AC.

   Multicast frames may be replicated by a PE, so of course the
   information carried in multicast frames may travel on more than one
   PW and more than one egress AC.

   Thus with respect to a given frame, a PW may be said to associate a
   number of ACs.  If these ACs are of the same technology (e.g., both
   ATM, both Ethernet, both Frame Relay) the PW is said to provide
   "homogeneous transport"; otherwise it is said to provide
   "heterogeneous transport". Heterogeneous transport requires that some
   sort of interworking function be applied.  There are at least three
   different approaches to interworking:

      1. One of the CEs may perform the interworking locally.  For
         example, if CE1 attaches to PE1 via ATM, but CE2 attaches to
         PE2 via Ethernet, then CE1 may decide to send/receive Ethernet
         frames over ATM, using the RFC2684 "LLC Encapsulation for
         Bridged Protocols".  In such a case, PE1 would need to know
         that it is to terminate the ATM VC locally, and only
         send/receive Ethernet frames over the PW.

      2. One of the PEs may perform the interworking.  For example, if
         CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via Frame
         Relay, PE1 may provide the "ATM/FR Service Interworking"
         function.  This would be transparent to the CEs, and the PW
         would carry only Frame Relay frames.

      3. IPLS could be used.  In this case the "frames" carried by the
         PW are IP datagrams, and the two PEs need to cooperate in order
         to spoof various L2-specific procedures used by IP (see section

3.2.3. Forwarders

   In all types of L2VPN, a PE, say PE1, receives a frame over an AC,
   and forwards it over a PW to another PE, say PE2.  PE2 then forwards
   the frame out on another AC.

   The case in which PE1 and PE2 are the same device is an important
   case to handle correctly, in order to provide the L2VPN service
   properly. However, as this case does not require any protocol, we do
   not further address it in this document.

Andersson, et al.                                              [Page 13]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   When PE1 receives a frame on a particular AC, it must determine the
   PW on which the frame must be forwarded.  In general, this is done by

     - the incoming AC,

     - possibly the contents of the frame's Layer2 header, and

     - possibly some forwarding information which may be statically or
       dynamically maintained.

   If dynamic or static forwarding information is considered, the
   information is specific to a particular L2VPN instance (i.e., to a
   particular VPN).

   Similarly, when PE2 receives a frame on a particular PW, it must
   determine the AC on which the frame must be forwarded. This is done
   by considering:

     - the incoming PW,

     - possibly the contents of the frame's Layer2 header, and

     - possibly some forwarding information which may be statically or
       dynamically maintained.

   If dynamic or static forwarding information is considered, the
   information is specific to a particular L2VPN instance (i.e. to a
   particular VPN).

   The procedures used to make the forwarding decision are known as a
   "forwarder".  We may think of a PW as being "bound", at each of its
   endpoints, to a forwarder.  The forwarder in turn "binds" the PWs to
   ACs. Different types of L2VPN have different types of forwarders.

   For instance, a forwarder may bind a single AC to a single PW,
   ignoring all frame contents and using no other forwarding
   information.  Or a forwarder may bind an AC to a set of PWs and ACs,
   moving individual frames from AC to PW, from a PW to an AC or from AC
   to AC by comparing information from the frame's Layer2 header to
   information in a forwarding database. This is discussed in more
   detail below, as we consider the different L2VPN types.

Andersson, et al.                                              [Page 14]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

3.2.4. Tunnels

   A PW is carried in a "tunnel" from PE1 to PE2.  We assume that an
   arbitrary number of PWs may be carried in a single tunnel; the only
   requirement is that the PWs all terminate at PE2.

   We do not even require that all the PWs in the tunnel originate at
   PE1; the tunnels may be multipoint-to-point tunnels.  Nor do we
   require that all PWs between the same pair of PEs travel in the same
   tunnel.  All we require is that when a frame traveling through such a
   tunnel arrives at PE2, PE2 will be able to associate it with a
   particular PW.

   (While one can imagine tunneling techniques that only allow one PW
   per tunnel, they have evident scalability problems, and we do not
   consider them further.)

   There are a variety of different tunneling technologies which may be
   used for the PE-PE tunnels.  All that is really required is that the
   tunneling technologies allow the proper demultiplexing of the
   contained PWs.  The tunnels might be MPLS LSPs, L2TP tunnels, IPsec
   tunnels, MPLS- in-IP tunnels, etc.  Generally the tunneling
   technology will require the use of an encapsulation that contains a
   demultiplexor field, where the demultiplexor field is used to
   identify a particular PW. Procedures for setting up and maintaining
   the tunnels are not within the scope of this framework. (But see
   section 3.2.6, "Pseudowire Signaling".)

   If there are multiple tunnels from PE1 to PE2, it may be desirable to
   assign a particular PE1-PE2 PW to a particular tunnel based on some
   particular characteristics of the PW and/or the tunnel. For example,
   perhaps different tunnels are associated with different QoS
   characteristics, and different PWs require different QoS. Procedures
   for specifying how to assign PWs to tunnels are out of scope of the
   current framework.

   Though point-to-point PWs are bidirectional, the tunnels in which
   they travel need not be either bidirectional or point-to-point. For
   example, a point-to-point PW may travel within a unidirectional
   multipoint-to- point MPLS LSP.

3.2.5. Encapsulation

   As L2VPN packets are carried in pseudowires, standard pseudowire
   encapsulation formats and techniques (as specified by the IETF's PWE3
   WG) should be used wherever applicable.

Andersson, et al.                                              [Page 15]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   Generally the PW encapsulations will themselves be encapsulated
   within a tunnel encapsulation, as determined by the specification of
   the tunneling protocol.

   It may be necessary to define additional PW encapsulations to cover
   areas that are of importance for L2VPN, but may not be within the
   scope of PWE3. Heterogeneous transport may be an instance of this.

3.2.6. Pseudowire Signaling

   Procedures for setting up and maintaining the PWs themselves are
   within the scope of this framework.  This includes procedures for
   distributing demultiplexor field values, even though the
   demultiplexor field, strictly speaking, belongs to the tunneling
   protocol rather than to the PW.

   The signaling for a point-to-point pseudowire must perform the
   following functions:

     - Distribution of the demultiplexor.

       Since many PWs may be carried in a single tunnel, the tunneling
       protocol must assign a demultiplexor value to each PW. These
       demultiplexors must be unique with respect to a given tunnel (or
       with some tunneling technologies, unique at the egress PE).
       Generally, the PE which is the egress of the tunnel will select
       the demultiplexor values, and will distribute them to the PE(s)
       which is (are) the ingress(es) of the tunnel. This is the
       essential part of the PW setup procedure.

       Note that, as is usually the case in tunneling architectures, the
       demultiplexor field belongs to the tunneling protocol, not to the
       protocol being tunneled. For this reason, the PW setup protocols
       may be extensions of the control protocols for setting up the

     - Selection of the Forwarder at the Remote PE.

       The signaling protocol must contain enough information to enable
       the remote PE to select the proper forwarder to which the PW is
       to be bound. We can call this information the "Remote Forwarder
       Selector". The information that is required will depend on the
       type of L2VPN being provided and on the provisioning model (see
       sections 3.3.1 and 3.4.2) being used.  The Remote Forwarder
       Selector may uniquely identify a particular Forwarder, or it may
       identify an attribute of Forwarders. In the latter case, it would
       select whichever Forwarder has been provisioned with that

Andersson, et al.                                              [Page 16]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003


     - Support pseudowire emulations.

       To the extent that a particular PW must emulate the signaling of
       a particular Layer2 technology, the PW signaling must provide the
       necessary functions.

     - Distribution of State Changes.

       Changes in the state of an AC may need to be reflected in changes
       to the state of the PW to which the AC is bound, and vice versa.
       The specification as to which changes need to be reflected in
       what way would generally be within the province of the PWE3 WG.

     - Establish pseudowire characteristics.

       To the extent that one or more characteristics of a PW must be
       known to and/or agreed upon by both endpoints, the signaling must
       allow for the necessary interaction.

   As specified above, signaling for point-to-point PWs must pass enough
   information to allow a remote PE to properly bind a PW to a
   Forwarder, and to associate a particular demultiplexor value with
   that PW. Once the two PEs have done the proper PW/Forwarder bindings,
   and have agreed on the demultiplexor values, the PW may be considered
   to have been set up. If it is necessary to negotiate further
   characteristics or parameters of a particular PW, or to passing
   status information for a particular PW, the PW may be identified by
   the demultiplexor value.

   Signaling procedures for point-to-point pseudowires are most commonly
   point-to-point procedures that are executed by the two PW endpoints.
   There are however proposals to use point-to-multipoint signaling for
   setting up point-to-point pseudowires, so this is included in the
   framework. When PWs are themselves point-to-multipoint, it is also
   possible to use either point-to-point signaling or point-to-
   multipoint signaling to set them up. This is discussed in the
   remainder of this section. Point-to-Point Signaling

   There are several ways to do the necessary point-to-point signaling.
   Among them are:

Andersson, et al.                                              [Page 17]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

     - LDP

       LDP extensions can be defined for pseudowire signaling. See for
       example [PWE3-LDP], [L2VPN-SIGNALING].  This form of signaling
       can be used for pseudowires which are to be carried in MPLS
       "tunnels", or in MPLS-in-something-else tunnels (e.g., [MPLS-IP-

     - L2TP

       L2TP [L2TP-BASE] can be used for pseudowire signaling, resulting
       in pseudowires that are carried as "sessions" within L2TP
       tunnels.  Pseudowire-specific extensions to L2TP may also be

   Other methods may be possible as well.

   It is possible to have one control connection between a pair of PEs,
   which is used to control many PWs.

   The use of point-to-point signaling for setting up point-to-point PWs
   is straightforward.  Multipoint-to-point PWs can also be set up by
   point- to-point signaling, as the remote PEs do not necessarily need
   to know whether the PWs are multipoint-to-point or point-to-point.
   In some signaling procedures, the same demultiplexor value may be
   assigned to all the remote PEs. Point-to-Multipoint Signaling

   Consider the following situation:

     - It is necessary to set up a set of PWs, all of which have the
       same characteristics.

     - It is not necessary to use the PW signaling protocol to pass PW
       state changes.

     - For each PW in the set, the same value of the Remote Forwarder
       Selector can be used.

   Call these the "Environmental Conditions".

   Suppose also that there is some mechanism by which, given a range of
   demultiplexor values, each of a set of PEs can make a unique and
   deterministic selection of a single value from within that range.
   Call this the "Demultiplexor Condition".  Alternatively, suppose that

Andersson, et al.                                              [Page 18]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   one is trying to set up a multipoint-to-point PW rather than a
   point-to-point PW. Call this the "Multipoint Condition".


     - The Environmental Conditions hold, and

     - Either

         * the Demultiplexor Condition holds, or

         * the Multipoint Condition holds,

   then for a given set of PWs which terminate at egress PE1, the
   information which PE1 needs to send to the ingress PE(s) of each
   pseudowire in the set is exactly the same.  All the ingress PE(s)
   receive the same Forwarder Selector value.  They all receive the same
   set of PW parameters (if any). And either they all receive the same
   demultiplexor value (if the PW is multipoint-to-point) or they all
   receive a range of demultiplexor values from which each can choose a
   unique demultiplexor value for itself.

   Rather than connecting to each ingress PE and replicating the same
   information, it may make sense either to multicast the information,
   or to send the information once to a "reflector", which will then
   take responsibility for distributing the information to the other

   We refer to this sort of technique as "point-to-multipoint"
   signaling. It would, for example, be possible to use BGP to do the
   signaling, with the PEs being BGP peers not of each other, but of one
   or more BGP route reflectors.

   Such a scheme, based Multi-protocol Extensions to BGP, is proposed in
   [L2VPN-BGP]. Inter-AS Considerations

   Pseudowires may need to run from a PE in one Service Provider's
   network to a PE in another Service Provider's network. This means
   that the signaling to set up the PEs must be able to cross network
   boundaries. All known proposals for signaling are able to do this. It
   is especially advisable to use some form of authentication between
   the two PW endpoints in this case.

Andersson, et al.                                              [Page 19]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

3.2.7. Service Quality

   Service Quality refers to the ability for the network to deliver a
   Service level Specification (SLS) for service attributes such as
   protection, security and Quality of Service (QoS).  The service
   quality provided depends on the subscriber's requirements, and can be
   characterized by a number of performance metrics.

   The necessary Service Quality must be provided on the ACs as well as
   on the PWs.  Mechanisms for providing Service Quality on the PWs may
   be PW- specific or tunnel-specific; in the latter case, the
   assignment of a PW to a tunnel may depend on the Service Quality. Quality of Service (QoS)

   QoS describes the queuing behavior applied to a particular "flow", in
   order to achieve particular goals of precedence, throughput, delay,
   jitter, etc.

   Based on the customer Service Level Agreement (SLA), traffic from
   customer can be prioritized, policed and shaped for QoS requirements.
   The queuing and forwarding policies can preserve the packet order and
   QoS parameters of customer traffic.  The class of services can be
   mapped from information in the customer frames, or it can be
   independent of the frame content.

   QoS functions can be listed as follows:

     - Customer Traffic Prioritization: L2VPN services could be best
       effort or QoS guaranteed. Traffic from one customer might need to
       be prioritized over others when sharing same network resources.
       This requires capabilities within the L2VPN solution to classify
       and mark priority to QoS guaranteed customer traffic.

     - Proper queuing behavior would be needed at the egress AC, and
       possibly within the backbone network as well. If queuing behavior
       must be controlled within the backbone network, the control might
       be based on CoS information in the MPLS or IP header, or it might
       be achieved by nesting particular tunnels within particular
       traffic engineering tunnels.

     - Policing: This ensures that a user of L2VPN services uses network
       resources within the limits of the agreed SLA. Any excess L2VPN
       traffic can be rejected or handled differently based on provider

Andersson, et al.                                              [Page 20]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

     - Policing would generally be applied at the ingress AC.

     - Shaping: Under some cases the random nature of L2VPN traffic
       might lead to sub-optimal utilization of network resources.
       Through queuing and forwarding mechanisms the traffic can be
       shaped without altering the packet order.

     - Shaping would generally be applied at the ingress AC. Resiliency

   Resiliency describes the ability of the L2VPN infrastructure to
   protect a flow from network outage, so that service remains available
   in the presence of failures.

   L2VPN, like any other service, is subject to failures such as link,
   trunk and node failures, both in the SP's core network infrastructure
   and on the ACs.

   It is desirable that the failure be detected "immediately" and
   protection mechanisms allow fast restoration times to make L2VPN
   service almost transparent to these failures to the extent possible,
   based on the level of resiliency.  Restoration should take place
   before the CEs can react to the failure.  Essential aspects of
   providing resiliency are:

     - Link/Node failure detection: Mechanisms within the L2VPN service
       should allow for link or node failures that impact the Service,
       and should be detected immediately.

     - Resiliency policy: The way in which a detected failure is handled
       will depend upon the restoration policy of the SLA associated
       with the L2VPN service specification. It may need to be handled
       immediately, or it may need to be handled only if no other
       critical failure needs protection resources, or it may be
       completely ignored if it is within the bounds of the "acceptable
       downtime" allowed by the L2VPN service.

     - Restoration Mechanisms: The L2VPN solutions could allow for
       physical level protection, logical level protection or both.  For
       example, by connecting customers over redundant and physically
       separate ACs to different provider customer-facing devices, one
       AC can be maintained as active while the other could be marked as
       a backup; upon the failure detection across the primary AC, the
       backup could become active.

Andersson, et al.                                              [Page 21]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   To a great extent, resiliency is a matter of having appropriate
   failure and recovery mechanisms in the network core, including
   "ordinary" adaptive routing as well as "fast reroute" capabilities.
   The ability to support redundant ACs between CEs and PEs also plays a

3.2.8. Management

   An L2VPN solution can provide mechanisms to manage and monitor
   different L2VPN components. From a Service Level Agreement (SLA)
   perspective, L2VPN solutions could allow monitoring of L2VPN service
   characteristics and offer mechanisms used by Service Providers to
   report such monitored statistical data.  Trouble-shooting and
   verification of operational and maintenance activities of L2VPN
   services are essential requirements for Service Providers.

3.3. VPWS

   A VPWS is an L2VPN service in which each forwarder binds exactly one
   AC to exactly one PW.  Frames received on the AC are transmitted on
   the PW; frames received on the PW are transmitted on the AC.  The
   content of a frame's Layer2 header plays no role in the forwarding
   decision, except insofar as the Layer2 header contents are used to
   associate the frame with a particular AC (as, e.g., the DLCI field of
   a Frame Relay frame identifies the AC).

   A particular combination of <AC, PW, AC> forms a "virtual circuit"
   between two CE devices.

   A particular VPN (VPWS instance) may be thought of as a collection of
   such virtual circuits, or as an "overlay" of PWs on the MPLS or IP
   backbone. This creates an overlay topology that is in effect the
   "virtual backbone" of a particular VPN.

   Whether two virtual circuits are said to belong to the same VPN or
   not is an administrative matter, based on the agreements between the
   SPs and their customers.  This may impact the provisioning model
   (discussed below).  It may also affect how particular PWs are
   assigned to tunnels, the way QoS is assigned to particular ACs and
   PWs, etc.

   Note that VPWS makes use of point-to-point PWs exclusively.

   VPWS solutions are found e.g. in [L2VPN-BGP] and [L2VPN-SIGNALING].

Andersson, et al.                                              [Page 22]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

3.3.1. Provisioning and Auto-Discovery

   Provisioning a VPWS is a matter of:

      1. Provisioning the ACs

      2. Providing the PEs with the necessary information to enable them
         to set up PWs between ACs to result in the desired overlay

      3. Configuring the PWs with any necessary characteristics Attachment Circuit Provisioning

   In many cases, the ACs must be individually provisioned on the PE
   and/or CE. This will certainly be the case if the CE/PE attachment
   technology is a switched network, such as ATM or FR, and the VCs are
   PVCs rather than SVCs. It is also the case whenever the individual
   Attachment Circuits need to be given specific parameters (e.g., QoS
   parameters, guaranteed bandwidth parameters) that differ from circuit
   to circuit.

   There are also cases in which ACs might not have to be individually
   provisioned.  E.g., if an AC is just an MPLS LSP running between a CE
   and a PE, it could be set up as the RESULT of a PW being set up,
   rather than having to be provisioned BEFORE the PW can be set up. The
   same may apply whenever the AC is a Switched Virtual Circuit of any
   sort, though in this case, various policy controls might need to be
   provisioned, e.g., limiting the number of ACs that can be set up
   between a given CE and a given PE.

   Issues such as whether the Attachment Circuits need to be
   individually provisioned or not, whether they are Switched VCs or
   Permanent VCs, and what sorts of policy controls may be applied, are
   implementation and deployment issues, and are considered to be out of
   scope of this framework. PW Provisioning for Arbitrary Overlay Topologies

   In order to support arbitrary overlay topologies, it is necessary to
   allow the provisioning of individual PWs.  In this model, when a PW
   is provisioned on a PE device, it is locally bound to a specific AC.
   It is also provisioned with information that identifies a specific AC
   at a remote PE.

Andersson, et al.                                              [Page 23]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   There are basically two variations of this provisioning model:

     - Two-sided provisioning

       With two-sided provisioning, each PE that is at the end of a PW
       is provisioned with the following information:

         * Identifier of the Local AC to which the PW is to be bound

         * PW type and parameters

         * IP address of the remote PE (i.e., the PE which is to be at
           the remote end of the PW)

         * Identifier which is meaningful to the remote PE, and which
           can be passed in the PW signaling protocol to enable the
           remote PE to bind the PW to the proper AC.  This can be an
           identifier of the pseudowire (as in [PWE3-LDP]), or an
           identifier of the remote AC (as in [L2VPN-SIGNALING]).  If a
           PW identifier is used, it must be unique at each of the two
           PEs. If an AC identifier is used, it need only be unique at
           the remote PE.

       This identifier is then used as the Remote Forwarder Selector
       when signaling is done (see

     - Single-sided Provisioning

       With single sided provisioning, a PE at one end of a PW is
       provisioned with the following information:

         * Identifier of the Local AC to which the PW is to be bound

         * PW type and parameters

         * Globally unique identifier of remote AC

       This identifier is then used as the Forwarder Selector when
       signaling is done (see section

       In this provisioning model, the IP address of the remote PE is
       not provisioned.  Rather, the assumption is that an auto-
       discovery scheme will be used to map the globally unique
       identifier to the IP address of the remote PE, along with an
       identifier (perhaps unique only at the latter PE) for an AC at
       that PE.  The PW signaling protocol can then make a connection to
       the remote PE, passing the AC identifier, so that the remote PE
       binds the PW to the proper AC.  (See, for example, [L2VPN-

Andersson, et al.                                              [Page 24]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003


       This scheme requires provisioning of the PW at only one PE, but
       does not eliminate the need (if there is a need) to provision the
       ACs at both PEs.

   These provisioning models fit well with the use of point-to-point
   signaling. When each PW is individually provisioned, as the
   conditions necessary for the use of point-to-multipoint signaling do
   not hold. Colored Pools PW Provisioning Model

   Suppose that at each PE, sets of ACs are gathered together into
   "pools", and that each such pool is assigned a "color".  (For
   example, a pool might contain all and only the ACs from this PE to a
   particular CE.) Now suppose we impose the following rule: whenever
   PE1 and PE2 have a pool of the same color, there will be a PW between
   PE1 and PE2 which is bound at PE1 to an arbitrarily chosen AC from
   that pool, and at PE2 to an arbitrarily chosen AC from that pool.
   (We do not rule out the case where a single PE has multiple pools of
   a given color.)

   For example, each pool in a particular PE might represent a
   particular CE device, with the ACs in the pool being the ACs
   connecting that CE to that PE.  The color might be a VPN-id.
   Application of this provisioning model would then lead to a full CE-
   to-CE mesh within the VPN, where every CE in the VPN has a virtual
   circuit to every other CE within the VPN.

   More specifically, to provision VPWS according to this model, one
   provisions a set of pools, and configures each pool with the
   following information:

     - The set of ACs that belong to the pool (with no AC belonging to
       more than one pool)

     - The color

     - A pool identifier that is unique at least relative to the color.

       An auto-discovery procedure is then used to map each color into a
       list of ordered pairs <IP address of PE, pool id>.  The
       occurrence of a pair <X, Y> on this list means that the PE at IP
       address X has a pool with pool id Y which is of the specified

Andersson, et al.                                              [Page 25]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

       This information can be used to support several different
       signaling techniques.  One possible technique proceeds as

     - A PE finds that it has a pool of color C.

     - Using auto-discovery, it obtains the set of ordered pairs <X,Y>
       for color C.

     - For each such pair <X,Y>, it:

         * removes an AC from the pool

         * binds the AC to a particular PW

         * signals PE X via point-to-point signaling that the PW is to
           be bound to an AC from pool Y.
   This sort of technique is discussed in [L2VPN-SIGNALING].

   Another possible signaling technique is the following:

     - A PE finds that it has a pool of color C, containing n ACs.

     - It binds each AC to a PW, creating a set of PWs.  This set of PWs
       is then organized into a sequence.  (For instance, each PW may be
       associated with a demultiplexor field value, and the PWs may then
       be sequenced according to the numerical value of their respective

     - Using auto-discovery, it obtains the list of PE routers that have
       one or more pools of color C.

     - It signals each such PE router, specifying the sequence Q of PWs.

     - If PE X receives such a signal, and PE X has a pool Y of the
       specified color, it:

         * removes an AC from the pool

         * binds the AC to the PW which is the "Yth" PW in the sequence

   This presumes, of course, that the pool identifiers are or can be
   uniquely mapped into small ordinal numbers; assigning the pool
   identifiers in this way becomes a requirement of the provisioning

   Note that since this technique signals the same information to all

Andersson, et al.                                              [Page 26]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   the remote PEs, it can be supported via point-to-multipoint
   signaling.  This sort of scheme is discussed in [L2VPN-BGP].

   This provisioning model can be applied as long as the following
   conditions hold:

     - There is no need to provision different characteristics for the
       different PWs, and

     - It makes no difference which pairs of ACs are bound together by
       PWs, as long as both ACs in the pair come from like-colored
       pools, and

     - It is possible to construct the desired overlay topology simply
       by assigning colors to the pools.  (This is certainly simple if a
       full mesh is desired, or if a hub and spoke configuration is
       desired; creating arbitrary topologies is less simple, and
       perhaps not always possible.)

3.3.2. Requirements on Auto-Discovery Procedures

   Some of the requirements for auto-discovery procedures can be deduced
   from the above.

   To support the single-sided provisioning model, auto-discovery must
   be able to map a globally unique identifier (of a PW or of an
   Attachment Circuit) to an IP address of a PE.

   To support the colored pools provisioning model, auto-discovery must
   enable a PE to determine the set of other PEs that contain pools of
   the same color.

   Examples of suitable auto-discovery procedures can be found in
   Examples of suitable auto-discovery procedures can be found in

   These requirements enable the auto-discovery scheme to provide the
   information, which the PEs need to set up the PWs.

   There are additional requirements on the auto-discovery procedures
   that cannot simply be deduced from the provisioning model:

     - Particular signaling schemes may require additional information
       before they can proceed, and hence may impose additional
       requirements on the auto-discovery procedures.

Andersson, et al.                                              [Page 27]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

     - A given Service Provider may support several different types of
       signaling procedures, and thus the PEs may need to learn, via
       auto- discovery, which signaling procedures to use.

     - Changes in the configuration of a PE should be reflected by the
       auto-discovery procedures, within a timely manner, and without
       the need to explicitly reconfigure any other PE.

     - The auto-configuration procedures must work across service
       provider boundaries. This rules out, e.g., the use of schemes
       that piggyback the auto-discovery information on the backbone's

3.3.3. Heterogeneous Pseudowires

   Under certain circumstances, it may be desirable to have a PW that
   binds two ACs that use different technologies (e.g., one is ATM, one
   is Ethernet). There are a number of different ways, depending on the
   AC types, in which this can be done.  For example:

     - If one AC is ATM and one is FR, then standard ATM/FR Network
       Interworking can be used.  In this case, the PW might be signaled
       for ATM, with the Interworking function occurring between the PW
       and the FR AC.

     - A common encapsulation can be used on both ACs, e.g., if one AC
       is Ethernet and one is FR, an "Ethernet over FR" encapsulation
       can be used on the latter.  In this case, the PW could be
       signaled for Ethernet, with the processing of the Ethernet over
       FR encapsulation being local to the PE with the FR AC.

     - If it is known that the two ACs attach to IP routers or hosts,
       and carry only IP traffic, then one could use a PW which carries
       the IP packets, and the respective Layer2 encapsulations would be
       local matters for the two PEs.  However, if one of the ACs is a
       LAN and one is a point-to-point link, care would have to be taken
       to ensure that such procedures as ARP and Inverse ARP are
       properly handled; this might require some signaling, and some
       proxy functions. Further, if the CEs use a routing algorithm that
       has different procedures for LAN interfaces than for point-to-
       point interfaces, additional mechanisms may be required to ensure
       proper interworking.  These issues are discussed in [ARP-

Andersson, et al.                                              [Page 28]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

3.4. VPLS Emulated LANs

   A VPLS is an L2VPN service in which:

     - the ACs attach CE devices to PE bridge modules,

     - each PE bridge module is attached via an "emulated LAN interface"
       to an "emulated LAN"

   This is shown in Figure 3.

   In this section, we examine the functional decomposition of the VPLS
   Emulated LAN.  An Emulated LAN's ACs are the "emulated LAN
   interfaces" attaching PE bridge modules to the "VPLS Forwarder"
   modules (see Figure 3).  The payload on the ACs consists of ethernet
   frames, with or without VLAN headers.

   A given VPLS Forwarder in a given PE will have multiple ACs only if
   there are multiple bridge modules in that PE which attach to that
   Forwarder.  This scenario is included in the Framework, though
   discussion of its utility is out of scope.

   The set of VPLS Forwarders within a single VPLS are connected via
   PWs.  Two VPLS Forwarders will have a PW between them only if those
   two Forwarders are part of the same VPLS.  (There may be a further
   restriction that two VPLS Forwarders have a PW between them only if
   those two Forwarders belong to the same VLAN in the same VPN.)  A
   particular set of interconnected VPLS Forwarders is what constitutes
   a VPLS Emulated LAN.

   On a real LAN, any frame transmitted by one entity is received by all
   the others.  A VPLS Emulated LAN, however, behaves somewhat
   differently.  When a VPLS Forwarder receives a unicast frame over one
   of its Emulated LAN interfaces, the Forwarder does not necessarily
   send the frame to all the other Forwarders on that Emulated LAN.  A
   unicast frame need be sent to only one other Forwarder in order to be
   properly delivered to its destination MAC address.  If the
   transmitting Forwarder knows which other Forwarder needs to receive a
   particular unicast frame, it will send the frame to just that one
   Forwarder.  This forwarding optimization is an important part of any
   attempt to provide a VPLS service over a wide-area or metropolitan
   area network.

   In effect then each Forwarder behaves as a "Virtual Switch Instance"
   (VSI), maintaining a forwarding table in which maps MAC addresses to
   PWs.  The VSI is populated in much the same was as a standard bridge
   populates its forwarding table.  The VPLS Forwarders do MAC SA
   learning on frames received on PWs from other Forwarders, and must

Andersson, et al.                                              [Page 29]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   also do the related set of procedures, such as the aging out of
   address entries.  Frames with unknown DAs or multicast DAs must be
   "broadcast" by one Forwarder to all the others (on the same emulated
   LAN).  There are however a few important differences between the VPLS
   Forwarder VSI and the standard bridge forwarding function:

     - A VPLS Forwarder never learns the MAC SAs of frames which it
       receives on its ACs, it only learns the MAC SAs of frames which
       are received on PWs from other VPLS Forwarders;

     - The VPLS Forwarders of a particular emulated LAN do not
       participate in a spanning tree protocol with each other.  A
       "split horizon" technique is used to prevent forwarding loops.

   These points are discussed further in the next section.

   Note that the PE bridge modules which are on a given Emulated LAN may
   or may not run spanning tree protocol with each other over the
   Emulated LAN; whether they do so or not is outside the scope of the
   VPLS specifications. The PE bridge modules will do MAC address
   learning on the ACs.  The PE bridge modules also do MAC address
   learning on the Emulated LAN interfaces, but do not do MAC address
   learning on the PWs, as the PWs are "hidden" behind the Emulated LAN
   interface.  Conceptually, the PE bridge module's forwarding table and
   the VPLS Forwarder's VSI are distinct entities.  (Of course,
   particular implementations might combine these into a single table,
   but that is beyond the scope of this document.)

   A further issue does arise in the case where the PE bridges do run
   bridge control protocols with each other over the Emulated LAN.
   Bridge control protocols are generally designed to run in over a real
   LAN, and may presume, for their proper functioning, certain
   characteristics of the LAN, such as low latency and sequential
   delivery.  If the Emulated LAN does not provide these
   characteristics, the control protocols may not perform as expected
   unless special mechanisms are provided for carrying the control

   It should be noted that changes in the spanning tree (if any) of a
   customer network, or in the spanning tree (if any) of the PE bridges,
   may cause certain MAC addresses to change their location from one PE
   to another.  These changes may not be visible to the VPLS Forwarders,
   which means that those MAC addresses might become unreachable until
   they are aged out of the first PE's VSI.  If this is not acceptable,
   some mechanism for communicating such changes to the VPLS Forwarders
   must be provided.

   VPLS solutions are found e.g. in [VPLS-L2TP-RAD], [VPLS-LDP], and

Andersson, et al.                                              [Page 30]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003


3.4.1. VPLS Overlay Topologies and Forwarding

   Within a single VPLS, the VPLS Forwarders are interconnected by PWs.
   The set of PWs thus forms an "overlay topology".

   The VPLS Forwarder VSIs are populated by means of MAC address
   learning.  That is, the VSI keeps track of which MAC SAs have been
   received over which PWs.  The presumption of course is that if a
   particular MAC address appears as the SA of a frame received over a
   particular PW, then frames which carry that MAC address in the DA
   field should be sent to the VSI which is at the remote end of the PW.
   In order for this presumption to be true, there must be a unique VSI
   at the remote end of the PW, which means that VSIs cannot be
   interconnected by means of multipoint-to-point PWs.  The PWs are
   necessarily either point-to-point or, possibly, point-to-multipoint.

   MAC learning over a point-to-point PW is done via the standard
   techniques as specified by IEEE, where the PW is treated by the VPLS
   Forwarder as a "bridge port". Of course, if a MAC address is learned
   from a point-to-multipoint PW, the VSI must indicate that packets to
   that address are to be sent over a point-to-point PW which leads to
   the root of that point-to-multipoint PW.

   The VSI forwarding decisions must be coordinated so that loop-free
   forwarding over the overlay topology is ensured.

   There are several possible types of overlay topologies:

     - Full mesh

       In a full mesh, every VSI in a given VPLS has exactly one point-
       to-point PW to every other VSI in that same VPLS.

       In this topology, loop free forwarding of frames is ensured by
       the following rule: if a VSI receives a frame, over a PW, from
       another VSI, it MUST NOT forward that frame over ANY other PW to
       any other VSI.  This ensures that once a frame traverses the
       Emulated LAN, it must be sent off the Emulated LAN.

       If a VSI receives, on one of its Emulated LAN interfaces, a
       unicast frame with a known DA, the frame is sent on exactly one
       point-to-point PW.

       If a VSI receives, on one of its Emulated LAN interfaces, a
       multicast frame or a unicast frame with unknown DA, it send a

Andersson, et al.                                              [Page 31]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

       copy of the frame to each other VSI in the same Emulated LAN.
       This can be done by replicating the frame and sending a copy over
       each point-to-point PW.  Alternatively, the full mesh of point-
       to-point PWs may be augmented with point-to-multipoint PWs, where
       each VSI in a VPLS is the transmitter on a single point-to-
       multipoint PW, and the receivers on that PW are all the other
       VSIs in that VPLS.

     - Tree Structured

       In a tree structured topology, every VSI in a particular VPLS is
       provisioned to be at a particular level in the tree.  A given VSI
       has at most one pseudowire leading to a higher level. The root of
       the tree is considered to be the highest level.

       In this topology, loop free forwarding of frames is ensured by
       the following rule: if a frame is received over a pseudowire from
       a higher level, it may not be sent over a pseudowire that leads
       to a higher level.

     - Tree with Meshed Highest Level

       In this variant of the tree-structured topology, there may be
       more than one VSI at the highest level, but the set of VSIs which
       are at the highest level must be fully meshed. To ensure loop
       free forwarding, we need to impose the rule that a frame can be
       sent on a pseudowire to the same or higher level only if it
       arrived over a pseudowire from a lower level, and frames arriving
       over PWs from the same level cannot be sent on PWs to the same

   Other overlay topologies are also possible, e.g., an arbitrary
   partial mesh of PWs among the VSIs of a VPLS.  Loop-freedom could
   then be assured by, for example, running spanning tree on the
   overlay.  These topologies are not further considered in this

   Note that loop freedom in the overlay topology does not necessarily
   ensure loop freedom in the overall customer LAN that contains the
   VPLS.  It does not even ensure loop freedom among the PE bridge
   modules.  It ensures only that when a frame is sent on the Emulated
   LAN, the frame will not loop endlessly before (or instead of) leaving
   the Emulated LAN.

   Improper configuration of the customer LAN or PE bridge modules may
   cause frames to loop, and frames that fall into such loops may
   transit the overlay topology multiple times. Procedures that enable
   the PE to detect and/or prevent such loops may be advisable.

Andersson, et al.                                              [Page 32]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

3.4.2. Provisioning and Auto-Discovery

   Each VPLS must be assigned a globally unique identifier. This can be
   thought of as a VPN-id.

   The ACs attaching the CEs to the PEs must be provisioned on both the
   PEs and the CEs.  A VSI for that VPLS must be provisioned on the PE,
   and the local ACs of that VPLS must be associated with that VSI. The
   VSI must be provisioned with the identifier of the VPLS to which it

   An auto-discovery scheme may be used by a PE to map a VPLS identifier
   into the set of remote PEs that have VSIs in that VPLS.  Once this
   set is determined, the PE can use pseudowire signaling to set up a PW
   to each of those VSIs. The VPLS identifier would serve as the
   signaling protocol's Forwarder Selector. This would result in a full
   mesh of PWs among the VSIs in a particular VPLS.

   If a single VPLS contains multiple VLANs, then it may be desirable to
   limit connectivity so that two VSIs are connected only if they have a
   VLAN in common.

   In this case, each VSI would need to be provisioned with one or more
   VLAN ids, and the auto-discovery scheme would need to map a VPLS
   identifier into pairs of <PE, VLAN id>.

   If a fully meshed topology of VSIs is not desired, then each VSI
   needs to be provisioned with additional information specifying its
   placement in the topology. This information would also need to be
   provided by the auto-discovery scheme.

   Examples of suitable auto-discovery procedures can be found in

   Alternatively, the single-sided provisioning method discussed in
   section could be used. As this is more complicated, it would
   only be used if it were necessary to associate individual PWs with
   individual characteristics. For example, if different guaranteed
   bandwidths were needed between different pairs of sites within a
   VPLS, the PWs would have to be individually provisioned.

3.4.3. Distributed PE

   Often when a VPLS type of service is provided, the CE devices attach
   to a provider-managed CPE device. This provider-managed CPE device
   may attach to CEs of multiple customers, especially if, e.g., there
   are multiple customers occupying the same building. However, this

Andersson, et al.                                              [Page 33]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   device is really part of the SP's network, hence may be considered to
   be a PE device.

   In some scenarios when a VPLS type of service is provided, the CE
   devices attach to a provider-managed intermediary device. This
   provider- managed device may attach to CEs of multiple customers.
   This may arise in a situation there multiple customers occupying the
   same building. This device is really part of the SP's network, and
   may for that reason be considered to be a PE device, however in the
   simplest case it is only performing aggregation and none of the
   function associated with a VPLS.

   Relative to the VPLS there are three different possibilities to
   allocate functions to a device in such a position in the provider

     - it can perform aggregation and pure Layer2 service only, in which
       case it does not really play the role of a PE device in a VPLS
       service. In this case the intermediary system must connect to
       devices that perform VPLS PE functionality; the intermediary
       device itself is not part of the VPLS architecture and has hence
       not been named in this architecture.

     - it can perform all the PE functions relevant for a VPLS, in such
       a case the device is called VPLS-PE, see [L2VPN-TERM]. This type
       of device will be connected to the core (P) routers.

   The PE functionality for a VPLS may be distributed between two
   devices, one "low-end" closer to the customer that performs e.g. the
   MAC-address learning and forwarding decisions, and one "high-end"
   that performs the control functions, e.g. establishing tunnels, PWs
   and VCs. We call the low-end device User-Facing PE (U-PE) and the
   high-end device Network- Facing PE (N-PE).

   It is conceivable that the U-PE may be placed very close to the
   customer, e.g. in a building with more than one customer.  The N-PE
   will presumably be placed on the SP's premises.  PE-POP, will
   presumably be placed on the SP's premises.

   The distributed case is potentially of interest for a number of
   possible reasons:

     - The N-PE may be a device that cannot easily implement the VSI
       functionality described above. E.g., perhaps the N-PE is a router
       which cannot perform the high speed MAC learning that is needed
       in order to implement a VSI forwarder. At the same time, the U-PE
       may need to be a low-cost device that also cannot implement the
       full set of VPLS functions.

Andersson, et al.                                              [Page 34]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

       This leads one to investigate further if there are sensible ways
       to split the VPLS PE functionality between the U-PE and the N-PE.

     - Generally, in the L2VPN architecture, the PEs are expected to
       participate as peers in the backbone routing protocol. Since the
       number of U-PEs is potentially very large relative to the number
       of N-PEs, this may be undesirable, as a matter of scaling the
       backbone routing protocol.

     - The U-PE may be a relatively inexpensive device that is unable to
       participate in the full range of signaling and/or auto-discovery
       procedures that are needed in order to provide the VPLS service.

   The VPLS functionality can be distributed between U-PE and N-PE in a
   number of different ways, and a number of different proposals have
   been made. They all presume that the U-PE will maintain a VSI
   forwarder, connected by PWs to the remote VSIs; the N-PE thus does
   not need to perform the VSI forwarding function. The proposals tend
   to differ with respect to the following questions:

     - Should the U-PEs perform full PW signaling to set up the PWs to
       remote VSIs? Or should the N-PEs do this signaling?

       Since the U-PEs need to be able to send packets on PWs to remote
       VSIs and receive packets on PWs from remote VSIs, if the PW
       signaling is done by the N-PE, there would have to be some form
       of "lightweight" (presumably) signaling between N-PE and U-PE
       that allows the PWs to be extended from N-PE to U-PE.

     - Should the U-PEs do their own auto-discovery, or should this be
       done by the N-PEs? In the latter case, the U-PEs may need to have
       some means of telling the N-PEs which VPLS's they are interested
       in, and the N-PEs must have some means of passing the results of
       the auto-discovery process to the U-PE.

       Whether it makes sense to split auto-discovery in this manner may
       depend on the particular auto-discovery protocol used. One would
       not expect the U-PEs to participate in a BGP-based auto-discovery
       scheme, e.g., but perhaps they would be expected to participate
       in a RADIUS-based auto-discovery scheme.

     - If a U-PE does not participate in routing, but is redundantly
       connected to two different N-PEs, can the U-PE still make an
       intelligent choice of the best N-PE to use as the "next hop" for
       traffic destined to a particular remote VSI? If not, can this
       choice be made as the result of some other sort of interaction
       between N-PE and U-PE? Or does this choice need to be established
       by provisioning?

Andersson, et al.                                              [Page 35]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

     - If a U-PE does not participate in routing, but does participate
       in full PW signaling, and if MPLS is being used, how can the the
       N-PE send the the U-PEs the labels that the U-PE needs to send
       traffic to its signaling peers. (If the U-PE did participate in
       routing, this would happen automatically.)

     - When a frame must be multicast, should the replication be done by
       the N-PE or the U-PE?

       These questions are not all independent; the way one answers some
       of them may influence the way one answers others.

3.4.4. Scaling issues in VPLS deployment

   In general, the PSN supports a VPLS solution with a tunnel from each
   VPLS-PE every other VPLS-PE participating in the same VPLS instance.
   Strictly, VPLS-PE's with more than one VPLS instance in common only
   need one tunnel, but for resource allocation reasons it might be
   necessary to establish several tunnels. For each VPLS service on a
   given VPLS-PE it needs to establish one pseudowire to every other
   VPLS-PE participating in that VPLS service. In total n*(n-1)
   pseudowires must be setup between the VPLS-PE routers. In large scale
   deployment this obviously creates scaling problems.  One way to
   address the scaling problems is to use hierarchy; this is discussed
   in [VPLS-LDP].

3.5. IP-only LAN-like Service (IPLS)

   If, instead of providing a general VPLS service, one wishes to
   provide a VPLS that is used only to connect IP routers or hosts
   (i.e., the CE devices are all assumed to be IP routers or hosts),
   then it is possible to make certain simplifications.

   In this environment, all Ethernet frames sent from a particular CE to
   a particular PE on a particular Attachment Circuit will have the same
   MAC Source Address. Thus rather than using address learning in the
   data plane to learn the MAC addresses, the PE can use the control
   plane to learn the MAC address. (See [ARP-MEDIATION] for a discussion
   of this.) This allows the PE to be implemented on devices that are
   not capable of doing MAC address learning in the data plane.

   To eliminate the need for MAC address learning on the PWs as well as
   on the ACs, the pseudowire signaling protocol would have to carry the
   MAC address from one pseudowire endpoint to the other. Each PE would
   perform proxy ARP to its directly attached CEs.

Andersson, et al.                                              [Page 36]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   Eliminating the need to do MAC address learning on the PWs eliminates
   the need for the PWs to be point-to-point. Multipoint-to-point PWs
   could be used instead.

   Unlike a VPLS, all the ACs in an IPLS would not necessarily have to
   carry Ethernet frames; only the IP packets would need to be passed
   across the network, not their Layer2 wrappers. However, this might
   require "translation" between "ARP" and "Inverse ARP". The set of
   routing protocols which could be carried across the IPLS might also
   be restricted. A fuller discussion of the advantages, disadvantages,
   and restrictions may be found in [ARP-MEDIATION].

4. Security Considerations

   The security considerations section of the L2VPN requirements
   document [L2VPN-REQ] addresses a number of areas that are potentially
   insecure aspects of the L2VPN.  These relate to both control plane
   and data plane security issues that may arise in the following areas:

     - issues fully contained in the provider network

     - issues fully contained in the customer network

     - issues in the customer-provider interface network

   These three areas are addressed below.

4.1. Provider Network Security Issues

   This section discusses security issues that only impact the SP's

   There are security issues having to do with the control connections
   that are used on a PE-PE basis for setting up and maintaining the

   A PE should not engage with another PE in a control connection unless
   it has some confidence that the peer is really a PE to which it
   should be setting up PWs.  Otherwise L2PVN traffic may go to the
   wrong place.  If control packets are maliciously and undetectably
   altered while in flight, denial of service, or alteration of the
   expected quality of service, may result.

   If peers discover each other dynamically (via some auto-discovery
   procedure), this presupposes that the auto-discovery procedures are

Andersson, et al.                                              [Page 37]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   themselves adequately trusted.

   PEs should not accept control connections from arbitrary entities; a
   PE should either be configured with its peers, or learn them from a
   trusted auto-configuration procedure.  If the peer is required to be
   within the same SP's network, then access control filters at the
   borders of that network can be used to prevent spoofing of the peer's
   source address.  If the peer is from another SP's network, then
   setting up such filters may be difficult or even impossible,
   depending on the way in which the two SPs are connected.  Even if the
   access filters can be set up, the level of assurance which they
   provide will be lower.

   Thus for inter-SP control connections, it is advisable to use some
   sort of cryptographic authentication procedure.  Control protocols
   which used TCP may use the TCP MD5 option to provide a measure of
   PE-PE authentication; this requires at least one shared secret
   between SPs.  The use of IPsec between PEs is also possible, and
   provides a greater degree of assurance, though at a greater cost.

   When LDP [RFC3036] is used as the control protocol, the LDP security
   considerations discussed in [RFC3036] are applicable.  Note that LDP
   uses both UDP as well as TCP.  It may be advisable to have some
   protection against spoofed UDP messages which appear to be from a
   valid peer; this requires further study.

   Future versions of this document will discuss the security
   considerations that apply to other signaling protocols.

   To limit the effect of Denial of Service attacks on a PE, some means
   of limiting the rate of processing of control plane traffic may be

   Unlike authentication and integrity, privacy of the signaling
   messages is not usually considered very important.  If it is needed,
   the signaling messages can be sent through an IPsec connection.

4.2. Provider-Customer Network Security Issues

   There are a number of security issues related to the access network
   between the provider and the customer.  This is also traditionally a
   network that is hard to protect physically.

   Typical security issues on the provider-customer interface include
   the following:

Andersson, et al.                                              [Page 38]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

     - Preventing unauthorized members joining an L2VPN

     - Ensuring correct customer interface configured

     - Ensuring correct service delimiting fields (VLAN, DLCI, etc.)

     - Preventing unauthorized access to PE

   As the access network for an L2VPN service is necessarily a layer 2
   network, it is preferable to use authentication mechanisms that do
   not presuppose any IP capabilities on the CE device.

   There are existing layer 2 protocols and best current practices to
   guard against these security issues.  For example, IEEE 802.1x
   defines authentication at the link level for access through an
   ethernet bridge; the Frame Relay Forum defines LMI extensions for
   authentication (FRF.17).

4.3. Customer Network Security Issues

   Even if all CE devices are properly authorized to attach to their PE
   devices, misconfiguration of the PE may interconnect CEs that are not
   supposed to be in the same L2VPN.

   In a VPWS, the CEs may run IPsec to authenticate each other.  Other
   layer 3 or layer 4 protocols may have their own authentication

   In a VPLS, CE-to-CE IPsec is even more problematic, as IPsec does not
   well support the multipoint configuration which is provided by the
   VPLS service.

   There may be alternative methods for achieving a degree of CE-to-CE
   authentication, if the L2VPN signaling protocol can carry opaque
   objects between the CEs, either inband (over the L2VPN), or out-of-
   band, through the participation of the signaling protocol.  This is
   for further study.

   The L2VPN procedures do not provide authentication, integrity, or
   privacy for the customer's traffic; if this is needed, it becomes the
   responsibility of the customer.

   If there is CE-to-CE control traffic (e.g., BPDUs), on whose
   integrity the customer's own layer 2 network depends, it may be
   advisable to send the control traffic using some more secure
   mechanism than is used for the data traffic.

Andersson, et al.                                              [Page 39]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

5. Intellectual Property Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive

6. Copyright Notice

   "Copyright (C) The Internet Society (date). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Andersson, et al.                                              [Page 40]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003


7. Normative References

   [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.

8. Informative References

   [RFC3036] Andersson, L et.al. "LDP Specification", RFC 3036, Jan

   [ARP-MEDIATION] Shah, J. et. al., "ARP Mediation for IP interworking
   of Layer 2 VPN", draft-shah-ppvpn-arp-mediation-02.txt, Work in
   Progress, June 2003.

   [BGP-AUTO] Ould-Brahim, H. et.al. "Using BGP as an Auto-Discovery
   Mechanism for Network-based VPNs",draft-ietf-l3vpn-bgpvpn-auto-
   00.txt, Work in Progress, July 2003.

   [IPLS] Shah H., et.al. "IP-Only LAN Service (IPLS)", draft-shah-
   ppvpn-ipls-02.txt, June 2003.

   [L2TP-BASE] Lau, J. "Layer Two Tunneling Protocol (Version 3)
   L2TPv3", draft-ietf-l2tpext-l2tp-base-10.txt", Work in Progress,
   April 2003.

   [L2VPN-BGP] Kompella, K. et.al. "Layer 2 VPNs Over Tunnels", draft-
   kompella-ppvpn-l2vpn-03.txt, April 2003.

   [L2VPN-REQ] Augustyn, W. et.al "Service Requirements for Layer 2
   Provider Provisioned Virtual Private Networks", draft-ietf-l2vpn-
   requirements-00.txt, Work in Progress, May 2003.

   [L2VPN-TERM] Andersson, L. and Madsen T. "VPN Terminology", draft-
   andersson-ppvpn-terminology-03.txt", Work in Progress, April 2003.

   [L2VPN-SIGNALING]  Rosen, E. "Provisioning Models and Endpoint
   Identifiers in L2VPN Signaling",  draft-ietf-l2vpn-signaling-00.txt,
   Work in Progress, September 2003.

   [L3VPN-FW] Callon, R. et.al. "A Framework for Layer 3 Provider
   Provisioned Virtual Private Networks", draft-ietf-l3vpn-framework-
   00.txt, Work in Progress, Internet Draft, July 2003.

Andersson, et al.                                              [Page 41]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

   [L3VPN-REQ] Carugi, M. et.al. "Service requirements for Layer 3
   Provider Provisioned Virtual Private Networks" draft-ietf-l3vpn-
   requirements-00.txt, Work in Progress, July 2003.

   [MPLS-IP-GRE] Worster, T., et. al., "Encapsulating MPLS in IP or
   GRE", draft-ietf-mpls-in-ip-or-gre-02.txt, Work in Progress, August

   [PWE3-ARCH] Bryant, S., "PWE3 Architecture", draft-ietf-pwe3-arch-
   05.txt, Work in Progress, August 2003.

   [PWE3-LDP] Martini, L. et.al. "Pseudowire Setup and Maintenance using
   LDP", draft-ietf-pwe3-control-protocol-03.txt, Work in Progress, July

   [VPLS-BGP] Kompella, K. "Virtual Private LAN Service", draft-ietf-
   l2vpn-vpls-bgp-00.txt, Work in Progress,  May 2003.

   [VPLS-L2TP-RAD] Heinanen, J, "Radius/L2TP Based VPLS", draft-
   heinanen-radius-l2tp-vpls-0-.txt, Work in Progress, February 2003.

   [VPLS-LDP] Lasserre, M. et.al. "Virtual Private LAN Services over
   MPLS", draft-ietf-l2vpn-vpls-ldp-00.txt, Work in progress, June 2003.

9. Authors and Acknowledgments

   This document is the outcome of discussions within a PPVPN Layer 2
   VPN design team, all of whose members could be considered to be co-
   authors.  Specifically, the co-authors are Loa Andersson, Waldemar
   Augustyn, Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti
   Kompella, Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile
   Radoaca, Eric Rosen, and Tissa Senevirathne.

   The authors would like to thank Marco Carugi for cooperation in
   setting up context, working directions and taking time for
   discussions in this space, Tove Madsen for valuable input and
   reviews, and Norm Finn, Matt Squires, and Ali Sajassi for valuable
   discussion of the VPLS issues.

Andersson, et al.                                              [Page 42]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

10. Authors' Contact Information

      Loa Andersson
      Email: loa@pi.se

      Eric C. Rosen
      Cisco Systems, Inc.
      1414 Massachusetts Avenue
      Boxborough, MA 01719
      Email: erosen@cisco.com

      Waldemar Augustyn
      Email: waldemar@nxp.com

      Marty Borden

      Juha Heinanen
      Song Networks, Inc.
      Hallituskatu 16
      33200 Tampere, Finland
      Email: jh@song.fi

      Kireeti Kompella
      Juniper Networks, Inc.
      1194 N. Mathilda Ave
      Sunnyvale, CA 94089
      Email: kireeti@juniper.net

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

Andersson, et al.                                              [Page 43]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

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

      Pascal Menezies
      Email: pascalm1@yahoo.com

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

      Vasile Radoaca
      Nortel Networks
      600 Technology Park
      Billerica, MA 01821
      Email: vasile@nortelnetworks.com

      Tissa Senevirathne
      1567 Belleville Way
      Sunnyvale CA 94087
      Email: tsenevir@hotmail.com

Andersson, et al.                                              [Page 44]

Internet Draft    draft-ietf-l2vpn-l2-framework-01.txt    September 2003

Andersson, et al.                                              [Page 45]