GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4664

Network Working Group L. Andersson, Ed. Request for Comments: 4664 Acreo AB Category: Informational E. Rosen, Ed.

                                                   Cisco Systems, Inc.
                                                        September 2006
      Framework for Layer 2 Virtual Private Networks (L2VPNs)

Status of This Memo

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

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

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

Andersson & Rosen Informational [Page 1] RFC 4664 Framework for Layer 2 VPNs September 2006

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 ...........................3
    1.4. Terminology ................................................4
 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 ................................11
         3.2.2. Pseudowires ........................................12
         3.2.3. Forwarders .........................................14
         3.2.4. Tunnels ............................................15
         3.2.5. Encapsulation ......................................16
         3.2.6. Pseudowire Signaling ...............................16
                3.2.6.1. Point-to-Point Signaling ..................18
                3.2.6.2. Point-to-Multipoint Signaling .............18
                3.2.6.3. Inter-AS Considerations ...................19
         3.2.7. Service Quality ....................................20
                3.2.7.1. Quality of Service (QoS) ..................20
                3.2.7.2. Resiliency ................................21
         3.2.8. Management .........................................22
    3.3. VPWS ......................................................22
         3.3.1. Provisioning and Auto-Discovery ....................23
                3.3.1.1. Attachment Circuit Provisioning ...........23
                3.3.1.2. PW Provisioning for Arbitrary
                         Overlay Topologies ........................23
                3.3.1.3. 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
    3.5. IP-Only LAN-Like Service (IPLS) ...........................36

Andersson & Rosen Informational [Page 2] RFC 4664 Framework for Layer 2 VPNs September 2006

 4. Security Considerations ........................................37
    4.1. Provider Network Security Issues ..........................37
    4.2. Provider-Customer Network Security Issues .................39
    4.3. Customer Network Security Issues ..........................39
 5. Acknowledgements ...............................................40
 6. Normative References ...........................................41
 7. Informative References .........................................41

1. Introduction

1.1. Conventions Used in This Document

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

1.2. Objectives and Scope of the Document

 This document provides a framework for Layer 2 Provider Provisioned
 Virtual Private Networks (L2VPNs).  This framework is intended to aid
 in standardizing protocols and mechanisms to support interoperable
 L2VPNs.
 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.
 Requirements for L2VPNs can be found in [RFC4665].
 This document provides reference models for L2VPNs and discusses the
 functional components of L2VPNs.  Specifically, this includes
 discussion of the technical issues that are important in the design
 of standards and mechanisms for L2VPNs, including those standards and
 mechanisms needed for interworking and security.
 This document discusses a number of different technical approaches to
 L2VPNs.  It tries to show how the different approaches are related,
 and to clarify the issues that may lead one to select one approach
 instead of another.  However, this document does not attempt to
 select any particular approach.

1.3. Layer 2 Virtual Private Networks

 There are two fundamentally different kinds of Layer 2 VPN service
 that a service provider could offer to a customer: Virtual Private
 Wire Service (VPWS) and Virtual Private LAN Service (VPLS).  There is
 also the possibility of an IP-only LAN-like Service (IPLS).

Andersson & Rosen Informational [Page 3] RFC 4664 Framework for Layer 2 VPNs September 2006

 A VPWS is a VPN service that supplies an L2 point-to-point service.
 As this is a point-to-point service, 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 emulates LAN service across a Wide Area
 Network (WAN).  With regard to the amount of state information that
 must be kept at the edges in order to support the forwarding
 function, it has 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.  (See Section 3.4.4.)
 Note that VPLS uses a service that does not have native multicast
 capability to emulate a service that does have native multicast
 capability.  As a result, there will be scalability issues with
 regard to the handling of multicast traffic in VPLS.
 A VPLS service may also impose longer delays and provide less
 reliable transport than would a native LAN service.  The standard LAN
 control protocols may not have been designed for such an environment
 and may experience scaling problems when run in that environment.

1.4. Terminology

 The list of the technical terms used when discussing L2VPNs may be
 found in the companion document [RFC4026].

Andersson & Rosen Informational [Page 4] RFC 4664 Framework for Layer 2 VPNs September 2006

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  |     | ----+----+  +-----+
                       |VPWS\---|-----|-----|/VPWS|
                       | 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 are defined in
 [RFC4026].  The attachment circuit and pseudowire are discussed in
 Section 3.  The PE does a simple mapping between the PW and
 attachment circuit based on local information; i.e., the PW
 demultiplexor and incoming/outgoing logical/physical port.

Andersson & Rosen Informational [Page 5] RFC 4664 Framework for Layer 2 VPNs September 2006

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 & Rosen Informational [Page 6] RFC 4664 Framework for Layer 2 VPNs September 2006

                       |-----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 of "VPLS Forwarder" modules connected by
 pseudowires, where the pseudowires may be traveling through PSN
 tunnels over a routed backbone.
 A "VPLS instance" consists of a set of VPLS Forwarders (no more than
 one per PE) connected by pseudowires.
 The functionality that the bridge module must support depends on the
 service that is being offered by the SP to its customers, as well as
 on various details of the SP's network.  At a 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 ([IEEE8021D]), running a spanning tree with each
 other.  Specification of the precise functionality that the bridge

Andersson & Rosen Informational [Page 7] RFC 4664 Framework for Layer 2 VPNs September 2006

 modules must have in particular circumstances is, however, out of
 scope of the current document.
 This framework specifies that each "bridge module" have a single
 "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 that may attach to a bridge module over a single
 "Emulated LAN interface".
 Thus the framework is compatible with at least the following three
 models:
  1. 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 [IEEE8021Q] tagging must be
      used to indicate which packets are in which VLANs.
  1. 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.  Since each VLAN uses
      a separate set of PWs, there is no need for 802.1Q tagging.
  1. 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 [RFC4026].

Andersson & Rosen Informational [Page 8] RFC 4664 Framework for Layer 2 VPNs September 2006

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

                VPLS-PE/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 the
 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 [RFC4026].

2.4. VPWS-PE and VPLS-PE

 The VPWS-PE and VPLS-PE are functionally very similar, in that they
 both use forwarders to map attachment circuits to pseudowires.  The
 only difference is that while the forwarder in a VPWS-PE does a one-
 to-one mapping between the attachment circuit and pseudowire, the
 forwarder in a VPLS-PE is a Virtual Switching Instance (VSI) that
 maps multiple attachment circuits to multiple pseudowires (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 exhibits the roles played by the various protocols and
 mechanisms, and thus makes it easier to understand the differences
 and similarities between various proposed L2VPN architectures.
 Section 3.1 contains an overview of some different types of L2VPNs.
 In Section 3.2, functional components that are common to the
 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, and type-specific features of the generic components.

Andersson & Rosen Informational [Page 9] RFC 4664 Framework for Layer 2 VPNs September 2006

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
 (SP).

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 [RFC4665].

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 Figure 3 indicates,
 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
 device, the LAN that 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 that is normal for bridges, which is based on MAC Source
 Address learning.

Andersson & Rosen Informational [Page 10] RFC 4664 Framework for Layer 2 VPNs September 2006

 VPLS is like VPWS in that forwarding is done without any
 consideration of the Layer3 header.  VPLS is unlike VPWS in that:
  1. VPLS allows the PE to use addressing information in a frame's L2

header to determine how to forward the frame; and

  1. 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 [RFC4665].

3.1.3. IP-Only LAN-Like Service (IPLS)

 An IPLS is very like a VPLS, except that:
  1. it is assumed that the CE devices are hosts or routers, not

switches; and

  1. it is assumed that the service will only carry IP packets and

supporting packets such as ICMP and ARP (in the case of IPv4) or

      Neighbor Discovery (in the case of IPv6); Layer 2 packets that
      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 PEs.  In all L2VPN types, a PE (PE1) receives a frame
 from a CE (CE1), and 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 that are necessary to transport L2 frames
 in any type of L2VPN service.

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

Andersson & Rosen Informational [Page 11] RFC 4664 Framework for Layer 2 VPNs September 2006

 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 it is
 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
 [RFC3985].
 Setting up and maintaining the PWs is the job of the PEs.  State
 information for a particular PW is maintained at the two PEs that 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 bidirectional; multipoint-to-point and point-to-multipoint
 PWs are always considered unidirectional.  Multipoint-to-point PWs
 can be used only when the PE receiving a frame does not need to
 infer, from the PW on which the frame was received, the identity of
 the frame's ingress AC.  Point-to-multipoint PWs may be useful when
 frames need to be multicast.
 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, and
 then on its egress AC.

Andersson & Rosen Informational [Page 12] RFC 4664 Framework for Layer 2 VPNs September 2006

 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 RFC 2684, "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 to 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.5).
 If heterogeneous PWs are used, the setup protocol must ensure that
 each endpoint knows the MTU of the remote AC.  If the two ACs do not
 have the same MTU, one of the following three procedures must be
 carried out:
  1. The PW is not allowed to come up.
  1. The endpoint at the AC with the larger MTU must reduce the AC's

MTU so that it is the same as the MTU of the remote AC.

  1. The two endpoints must agree to use a specified

fragmentation/reassembly procedure.

Andersson & Rosen Informational [Page 13] RFC 4664 Framework for Layer 2 VPNs September 2006

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 address it further in this document.
 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
 considering:
  1. the incoming AC;
  1. possibly the contents of the frame's Layer2 header; and
  1. possibly some forwarding information that 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:
  1. the incoming PW;
  1. possibly the contents of the frame's Layer2 header; and
  1. possibly some forwarding information that 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.

Andersson & Rosen Informational [Page 14] RFC 4664 Framework for Layer 2 VPNs September 2006

 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.

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.)
 A variety of different tunneling technologies 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.

Andersson & Rosen Informational [Page 15] RFC 4664 Framework for Layer 2 VPNs September 2006

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.
 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 that 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 and not to the PW.
 The signaling for a point-to-point pseudowire must perform the
 following functions:
  1. 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 that 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 tunnels.
  1. 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

Andersson & Rosen Informational [Page 16] RFC 4664 Framework for Layer 2 VPNs September 2006

      Selector".  The information that is required will depend on the
      type of L2VPN being provided and on the provisioning model being
      used (see Sections 3.3.1 and 3.4.2).  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
      attribute.
  1. Supporting 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.
  1. 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.
  1. Establishing 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 set up.  If it is necessary to negotiate further
 characteristics or parameters of a particular PW, or to pass 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.

Andersson & Rosen Informational [Page 17] RFC 4664 Framework for Layer 2 VPNs September 2006

3.2.6.1. Point-to-Point Signaling

 There are several ways to do the necessary point-to-point signaling.
 Among them are:
  1. LDP
      LDP [RFC3036] extensions can be defined for pseudowire
      signaling.  This form of signaling can be used for pseudowires
      that are to be carried in MPLS "tunnels", or in MPLS-in-
      something-else tunnels.
  1. L2TP
      L2TP [RFC2661] 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
      needed.
 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.

3.2.6.2. Point-to-Multipoint Signaling

 Consider the following conditions:
  1. It is necessary to set up a set of PWs, all of which have the

same characteristics.

  1. It is not necessary to use the PW signaling protocol to pass PW

state changes.

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

Andersson & Rosen Informational [Page 18] RFC 4664 Framework for Layer 2 VPNs September 2006

 deterministic selection of a single value from within that range.
 Call this the "Demultiplexor Condition".  Alternatively, suppose that
 one is trying to set up a multipoint-to-point PW rather than to set
 up a point-to-point PW.  Call this the "Multipoint Condition".
 If:
  1. The Environmental Conditions hold; and
  1. Either
  • the Demultiplexor Condition holds, or
  • the Multipoint Condition holds,
 then for a given set of PWs that terminate at egress PE1, the
 information that 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 connect to each ingress PE and replicate 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
 PEs.
 We refer to this sort of technique as "point-to-multipoint"
 signaling.  It would, for example, be possible to use BGP [RFC1771]
 to do the signaling, with PEs that are BGP peers not of each other,
 but of one or more BGP route reflectors [RFC2796].

3.2.6.3. 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 has the
 following implications:
  1. The signaling protocol that sets up the PWs must be able to

cross network boundaries. Of course, all IP-based protocols

      have this capability.
  1. The two PEs at the PW endpoints must be addressable and routable

from each other.

Andersson & Rosen Informational [Page 19] RFC 4664 Framework for Layer 2 VPNs September 2006

  1. The signaling protocol needs to allow each PW endpoint to

authenticate the other. To make use of the authentication

      capability, there would also need to be some method of key
      distribution that is acceptable to both administrations.

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.

3.2.7.1. 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 a
 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:
  1. 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.
  1. 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.

Andersson & Rosen Informational [Page 20] RFC 4664 Framework for Layer 2 VPNs September 2006

  1. 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 policy.
  1. Policing would generally be applied at the ingress AC.
  1. 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.
  1. Shaping would generally be applied at the ingress AC.

3.2.7.2. 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 that
 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:
  1. Link/Node failure detection: Mechanisms within the L2VPN service

should allow for link or node failures that impact the service,

      and that should be detected immediately.
  1. Resiliency policy: The way in which a detected failure is

handled will depend on 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.
  1. Restoration Mechanisms: The L2VPN solutions could allow for

physical level protection, logical level protection, or both.

      For example, by connecting customers over redundant and

Andersson & Rosen Informational [Page 21] RFC 4664 Framework for Layer 2 VPNs September 2006

      physically separate ACs to different provider customer-facing
      devices, one AC can be maintained as active, and the other could
      be marked as a backup; upon the failure detection across the
      primary AC, the backup could become active.
 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
 role.

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

Andersson & Rosen Informational [Page 22] RFC 4664 Framework for Layer 2 VPNs September 2006

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 topology; and
     3.  Configuring the PWs with any necessary characteristics.

3.3.1.1. 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.  For example, if an AC is just an MPLS LSP running
 between a CE and a PE, it could be set up as the RESULT of setting up
 a PW 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.

3.3.1.2. 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 & Rosen Informational [Page 23] RFC 4664 Framework for Layer 2 VPNs September 2006

 There are basically two variations of this provisioning model:
  1. 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 that is to be at

the remote end of the PW)

  • Identifier that is meaningful to the remote PE, and that 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 PW or an identifier of the remote AC.  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 3.2.6.1).
  1. 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 3.2.6.1).
      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.

Andersson & Rosen Informational [Page 24] RFC 4664 Framework for Layer 2 VPNs September 2006

      This scheme requires provisioning of the PW at only one PE, but
      it 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.

3.3.1.3. 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 that 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 that 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, for which the ACs in the pool are 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:
  1. The set of ACs that belong to the pool (with no AC belonging to

more than one pool)

  1. The color
  1. 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
      color.

Andersson & Rosen Informational [Page 25] RFC 4664 Framework for Layer 2 VPNs September 2006

      This information can be used to support several different
      signaling techniques.  One possible technique proceeds as
      follows:
  1. A PE finds that it has a pool of color C.
  1. Using auto-discovery, it obtains the set of ordered pairs <X,Y>

for color C.

  1. For each such pair <X,Y>, it:
  • removes an AC from the pool;
  • binds the AC to a particular PW; and
  • signals PE X via point-to-point signaling that the PW is to be

bound to an AC from pool Y.

 Another possible signaling technique is the following:
  1. A PE finds that it has a pool of color C, containing n ACs.
  1. 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 demultiplexors.)
  1. Using auto-discovery, it obtains the list of PE routers that

have one or more pools of color C.

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

PWs.

  1. 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; and
  • binds the AC to the PW that is the "Yth" PW in the sequence Q.
 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
 system.

Andersson & Rosen Informational [Page 26] RFC 4664 Framework for Layer 2 VPNs September 2006

 Note that since this technique signals the same information to all
 the remote PEs, it can be supported via point-to-multipoint
 signaling.
 This provisioning model can be applied as long as the following
 conditions hold:
  1. There is no need to provision different characteristics for the

different PWs;

  1. 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
  1. 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 is
      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.
 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:
  1. Particular signaling schemes may require additional information

before they can proceed and hence may impose additional

      requirements on the auto-discovery procedures.
  1. 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.

Andersson & Rosen Informational [Page 27] RFC 4664 Framework for Layer 2 VPNs September 2006

  1. 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.
  1. The auto-configuration procedures must work across service

provider boundaries. This rules out, e.g., use of schemes that

      piggyback the auto-discovery information on the backbone's IGP.

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:
  1. 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, where the Interworking function occurs between
      the PW and the FR AC.
  1. A common encapsulation can be used on both ACs, if for example,

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 processing of the Ethernet
      over FR encapsulation local to the PE with the FR AC.
  1. 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 that 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 procedures such 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 those for
      point-to-point interfaces, additional mechanisms may be required
      to ensure proper interworking.

Andersson & Rosen Informational [Page 28] RFC 4664 Framework for Layer 2 VPNs September 2006

3.4. VPLS Emulated LANs

 A VPLS is an L2VPN service in which:
  1. the ACs attach CE devices to PE bridge modules; and
  1. 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 that 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 needs to 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 that maps MAC
 addresses to PWs.  The VSI is populated in much the same way that a
 standard bridge populates its forwarding table.  The VPLS Forwarders
 do MAC Source Address (SA) learning on frames received on PWs from

Andersson & Rosen Informational [Page 29] RFC 4664 Framework for Layer 2 VPNs September 2006

 other Forwarders and must also do the related set of procedures, such
 as aging out 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:
  1. A VPLS Forwarder never learns the MAC SAs of frames that it

receives on its ACs; it only learns the MAC SAs of frames that

      are received on PWs from other VPLS Forwarders; and
  1. 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 that are on a given Emulated LAN may
 or may not run a 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 arises if the PE bridges 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 frames.
 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.

Andersson & Rosen Informational [Page 30] RFC 4664 Framework for Layer 2 VPNs September 2006

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 that carry that MAC address in the DA
 field should be sent to the VSI that 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 that 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:
  1. 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 an unknown DA, it sends
      a 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

Andersson & Rosen Informational [Page 31] RFC 4664 Framework for Layer 2 VPNs September 2006

      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.
  1. 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 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.
  1. 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 that
      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 that frames
      arriving over PWs from the same level cannot be sent on PWs to
      the same level.
 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 a spanning tree on the
 overlay.  These topologies are not further considered in this
 framework.
 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 & Rosen Informational [Page 32] RFC 4664 Framework for Layer 2 VPNs September 2006

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
 belongs.
 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.
 Alternatively, the single-sided provisioning method discussed in
 Section 3.3.1.2 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 provisioned individually.

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, for example,
 there are multiple customers occupying the same building.  However,
 this device is really part of the SP's network, hence may be
 considered a PE device.

Andersson & Rosen Informational [Page 33] RFC 4664 Framework for Layer 2 VPNs September 2006

 In some scenarios in which 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 if there are 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 performing only aggregation and none of the function
 associated with a VPLS.
 Relative to the VPLS there are three different possibilities for
 allocate functions to a device in such a position in the provider
 network:
  1. 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.
  1. it can perform all the PE functions relevant for a VPLS. In

such a case, the device is called VPLS-PE, see [RFC4026]. 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, for
    example, 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
    the User-Facing PE (U-PE) and the high-end device the 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.
    The distributed case is potentially of interest for a number of
    possible reasons:
  1. The N-PE may be a device that cannot easily implement the VSI

functionality described above. For example, perhaps the N-PE is

      a router that 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 & Rosen Informational [Page 34] RFC 4664 Framework for Layer 2 VPNs September 2006

      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.
  1. 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.
  1. 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:
  1. 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.
  1. 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 VPLSes 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, if for example, a
      BGP-based auto-discovery scheme, but perhaps they would be
      expected to participate in a RADIUS-based auto-discovery scheme.
  1. 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

Andersson & Rosen Informational [Page 35] RFC 4664 Framework for Layer 2 VPNs September 2006

      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?
  1. If a U-PE does not participate in routing but does participate

in full PW signaling, and if MPLS is being used, how can an N-PE

      send a U-PE the labels that the U-PE needs in order to be able
      to send traffic to its signaling peers?  (If the U-PE did
      participate in routing, this would happen automatically.)
  1. 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 to every other VPLS-PE participating in the same VPLS
 instance.  Strictly, VPLS-PEs 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.

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 use address learning in the
 data plane to learn the MAC addresses, the PE can use the control
 plane to learn the MAC address.  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.  In the case

Andersson & Rosen Informational [Page 36] RFC 4664 Framework for Layer 2 VPNs September 2006

 of IPv4, Each PE would perform proxy ARP to its directly attached
 CEs.  In the case of IPv6, each PE would send proxy Neighbor and/or
 Router Advertisements.
 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 Layer 2 wrappers.  However, if there
 are protocols that are specific to the Layer 2, but that provide, for
 example, address resolution services for Layer 3, it may then be
 necessary to "translate" (or otherwise interwork) one of these Layer
 2 protocols to the other.  For example, if an IPLS instance has an
 ethernet AC and a Frame Relay AC, and IPv4 is running on both,
 interworking between ARP and Inverse ARP might be required.
 The set of routing protocols that could be carried across the IPLS
 might also be restricted.
 An IPLS instance must have a particular IPLS-wide MTU; if there are
 different kinds of AC in an IPLS instance, and those different kinds
 of AC support different MTUs, all ACS must enforce the IPLS-wide MTU;
 an AC that cannot do this must not be allowed to join the IPLS
 instance.

4. Security Considerations

 The security considerations section of the L2VPN requirements
 document [RFC4665] 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:
  1. issues fully contained in the provider network
  1. issues fully contained in the customer network
  1. 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
 equipment.

Andersson & Rosen Informational [Page 37] RFC 4664 Framework for Layer 2 VPNs September 2006

 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
 pseudowires.
 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
 themselves adequately trusted.
 PEs should not accept control connections from arbitrary entities; a
 PE either should be configured with its peers or should 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 that 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.
 Any other security considerations that apply to the control protocol
 in general will also apply when the control protocol is used for
 setting up PWs.  If the control protocol uses UDP messages, it may be
 advisable to have some protection against spoofed UDP messages that
 appear to be from a valid peer; this requires further study.
 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
 desirable.
 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.

Andersson & Rosen Informational [Page 38] RFC 4664 Framework for Layer 2 VPNs September 2006

 If the PE cannot efficiently handle high volumes of multicast traffic
 for sustained periods, then it may be possible to launch a denial of
 service attack on a VPLS service by sending a PE a large number of
 frames that have either a multicast address or an unknown MAC address
 in their MAC Destination Address fields.  A similar denial of service
 attack can be mounted by sending a PE a large number of frames with
 bogus MAC Source Address fields.  The bogus addresses can fill the
 MAC address tables in the PEs, with the result that frames destined
 to the real MAC addresses always get flooded (i.e., multicast).  Note
 that this flooding can remove the (weak) confidentiality property of
 this or any other bridged network.

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:
  1. Ensuring that the correct customer interface is configured
  1. Preventing unauthorized access to the PE
  1. Preventing unauthorized access to a specific PE port
  1. Ensuring correct service delimiting fields (VLAN, DLCI, etc.)
 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
 methods.

Andersson & Rosen Informational [Page 39] RFC 4664 Framework for Layer 2 VPNs September 2006

 In a VPLS, CE-to-CE IPsec is even more problematic, as IPsec does not
 well support the multipoint configuration that 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.  For customers who really need these
 features or who do not trust their service providers to provide the
 level of security that they need, the L2VPN framework discussed in
 this document may not be satisfactory.  Such customers may consider
 alternative L2VPN schemes that are based not on an overlay of PWs,
 but on an overlay of IPsec tunnels whose endpoints are at the
 customer sites; however, such alternatives are not discussed in this
 document.
 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.
 In general, any means of mounting a denial of service attack on
 bridged networks generally can also be used to mount a denial of
 service attack on the VPLS service for a particular customer.  We
 have discussed here only those attacks that rely on features of the
 VPLS service that are not shared by bridged networks in general.

5. Acknowledgements

 This document is the outcome of discussions within a Layer 2 VPN
 design team, all of whose members could be considered 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 and Pekka Savola for valuable
 input and reviews; and Norm Finn, Matt Squires, and Ali Sajassi for
 valuable discussion of the VPLS issues.

Andersson & Rosen Informational [Page 40] RFC 4664 Framework for Layer 2 VPNs September 2006

6. Normative References

 [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3985]    Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.
 [RFC4026]    Andersson, L. and T. Madsen, "Provider Provisioned
              Virtual Private Network (VPN) Terminology", RFC 4026,
              March 2005.
 [RFC4665]    Augustyn, W., Ed. and Y. Serbest, Ed., "Service
              Requirements for Layer 2 Provider-Provisioned Virtual
              Private Networks (L2VPNs)", RFC 4665, September 2006.

7. Informative References

 [IEEE8021D]  IEEE 802.1D-2003, "IEEE Standard for Local and
              Metropolitan Area Networks:  Media Access Control (MAC)
              Bridges"
 [IEEE8021Q]  IEEE 802.1Q-1998, "IEEE Standards for Local and
              Metropolitan Area Networks:  Virtual Bridged Local Area
              Networks"
 [RFC1771]    Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
              (BGP-4)", RFC 1771, March 1995.
 [RFC2661]    Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol
              "L2TP"", RFC 2661, August 1999.
 [RFC2796]    Bates, T., Chandra, R., and E. Chen, "BGP Route
              Reflection - An Alternative to Full Mesh IBGP", RFC
              2796, April 2000.
 [RFC3036]    Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
              and B. Thomas, "LDP Specification", RFC 3036, January
              2001.

Andersson & Rosen Informational [Page 41] RFC 4664 Framework for Layer 2 VPNs September 2006

Authors' Addresses

 Loa Andersson
 Acreo AB
 EMail: loa@pi.se
 Eric C. Rosen
 Cisco Systems, Inc.
 1414 Massachusetts Avenue
 Boxborough, MA 01719
 EMail: erosen@cisco.com
 Waldemar Augustyn
 EMail: waldemar@wdmsys.com
 Marty Borden
 EMail: mborden@acm.org
 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: vach.kompella@alcatel.com

Andersson & Rosen Informational [Page 42] RFC 4664 Framework for Layer 2 VPNs September 2006

 Marc Lasserre
 Riverstone Networks
 5200 Great America Pkwy
 Santa Clara, CA 95054
 EMail: mlasserre@lucent.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: radoaca@hotmail.com
 Tissa Senevirathne
 1567 Belleville Way
 Sunnyvale CA 94087
 EMail: tsenevir@hotmail.com

Andersson & Rosen Informational [Page 43] RFC 4664 Framework for Layer 2 VPNs September 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

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

Acknowledgement

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

Andersson & Rosen Informational [Page 44]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4664.txt · Last modified: 2006/09/28 20:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki