doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc4762.txt b/doc/rfc/rfc4762.txt
new file mode 100644
index 0000000..5da458a
--- /dev/null
+++ b/doc/rfc/rfc4762.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                   M. Lasserre, Ed.
+Request for Comments: 4762                              V. Kompella, Ed.
+Category: Standards Track                                 Alcatel-Lucent
+                                                            January 2007
+
+
+               Virtual Private LAN Service (VPLS) Using
+              Label Distribution Protocol (LDP) Signaling
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+IESG Note
+
+   The L2VPN Working Group produced two separate documents, RFC 4761 and
+   this document, that perform similar functions using different
+   signaling protocols.  Be aware that each method is commonly referred
+   to as "VPLS" even though they are distinct and incompatible with one
+   another.
+
+Abstract
+
+   This document describes a Virtual Private LAN Service (VPLS) solution
+   using pseudowires, a service previously implemented over other
+   tunneling technologies and known as Transparent LAN Services (TLS).
+   A VPLS creates an emulated LAN segment for a given set of users;
+   i.e., it creates a Layer 2 broadcast domain that is fully capable of
+   learning and forwarding on Ethernet MAC addresses and that is closed
+   to a given set of users.  Multiple VPLS services can be supported
+   from a single Provider Edge (PE) node.
+
+   This document describes the control plane functions of signaling
+   pseudowire labels using Label Distribution Protocol (LDP), extending
+   RFC 4447.  It is agnostic to discovery protocols.  The data plane
+   functions of forwarding are also described, focusing in particular on
+   the learning of MAC addresses.  The encapsulation of VPLS packets is
+   described by RFC 4448.
+
+
+
+
+
+Lasserre & Kompella         Standards Track                     [Page 1]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+      2.1. Conventions ................................................4
+   3. Acronyms ........................................................4
+   4. Topological Model for VPLS ......................................5
+      4.1. Flooding and Forwarding ....................................6
+      4.2. Address Learning ...........................................6
+      4.3. Tunnel Topology ............................................7
+      4.4. Loop free VPLS .............................................7
+   5. Discovery .......................................................7
+   6. Control Plane ...................................................7
+      6.1. LDP-Based Signaling of Demultiplexers ......................8
+           6.1.1. Using the Generalized PWid FEC Element ..............8
+      6.2. MAC Address Withdrawal .....................................9
+           6.2.1. MAC List TLV ........................................9
+           6.2.2. Address Withdraw Message Containing MAC List TLV ...11
+   7. Data Forwarding on an Ethernet PW ..............................11
+      7.1. VPLS Encapsulation Actions ................................11
+      7.2. VPLS Learning Actions .....................................12
+   8. Data Forwarding on an Ethernet VLAN PW .........................13
+      8.1. VPLS Encapsulation Actions ................................13
+   9. Operation of a VPLS ............................................14
+      9.1. MAC Address Aging .........................................15
+   10. A Hierarchical VPLS Model .....................................16
+      10.1. Hierarchical Connectivity ................................16
+           10.1.1. Spoke Connectivity for Bridging-Capable Devices ...17
+           10.1.2. Advantages of Spoke Connectivity ..................18
+           10.1.3. Spoke Connectivity for Non-Bridging Devices .......19
+      10.2. Redundant Spoke Connections ..............................21
+           10.2.1. Dual-Homed MTU-s ..................................21
+           10.2.2. Failure Detection and Recovery ....................22
+      10.3. Multi-domain VPLS Service ................................23
+   11. Hierarchical VPLS Model Using Ethernet Access Network .........23
+      11.1. Scalability ..............................................24
+      11.2. Dual Homing and Failure Recovery .........................24
+   12. Contributors ..................................................25
+   13. Acknowledgements ..............................................25
+   14. Security Considerations .......................................26
+   15. IANA Considerations ...........................................26
+   16. References ....................................................27
+      16.1. Normative References .....................................27
+      16.2. Informative References ...................................27
+   Appendix A. VPLS Signaling using the PWid FEC Element .............29
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                     [Page 2]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+1.  Introduction
+
+   Ethernet has become the predominant technology for Local Area Network
+   (LAN) connectivity and is gaining acceptance as an access technology,
+   specifically in Metropolitan and Wide Area Networks (MAN and WAN,
+   respectively).  The primary motivation behind Virtual Private LAN
+   Services (VPLS) is to provide connectivity between geographically
+   dispersed customer sites across MANs and WANs, as if they were
+   connected using a LAN.  The intended application for the end-user can
+   be divided into the following two categories:
+
+   -  Connectivity between customer routers: LAN routing application
+
+   -  Connectivity between customer Ethernet switches: LAN switching
+      application
+
+   Broadcast and multicast services are available over traditional LANs.
+   Sites that belong to the same broadcast domain and that are connected
+   via an MPLS network expect broadcast, multicast, and unicast traffic
+   to be forwarded to the proper location(s).  This requires MAC address
+   learning/aging on a per-pseudowire basis, and packet replication
+   across pseudowires for multicast/broadcast traffic and for flooding
+   of unknown unicast destination traffic.
+
+   [RFC4448] defines how to carry Layer 2 (L2) frames over point-to-
+   point pseudowires (PW).  This document describes extensions to
+   [RFC4447] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic
+   across multiple sites that belong to the same L2 broadcast domain or
+   VPLS.  Note that the same model can be applied to other 802.1
+   technologies.  It describes a simple and scalable way to offer
+   Virtual LAN services, including the appropriate flooding of
+   broadcast, multicast, and unknown unicast destination traffic over
+   MPLS, without the need for address resolution servers or other
+   external servers, as discussed in [L2VPN-REQ].
+
+   The following discussion applies to devices that are VPLS capable and
+   have a means of tunneling labeled packets amongst each other.  The
+   resulting set of interconnected devices forms a private MPLS VPN.
+
+2.  Terminology
+
+   Q-in-Q               802.1ad Provider Bridge extensions also known
+                        as stackable VLANs or Q-in-Q.
+
+   Qualified learning   Learning mode in which each customer VLAN is
+                        mapped to its own VPLS instance.
+
+
+
+
+
+Lasserre & Kompella         Standards Track                     [Page 3]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   Service delimiter    Information used to identify a specific customer
+                        service instance.  This is typically encoded in
+                        the encapsulation header of customer frames
+                        (e.g., VLAN Id).
+
+   Tagged frame         Frame with an 802.1Q VLAN identifier.
+
+   Unqualified learning Learning mode where all the VLANs of a single
+                        customer are mapped to a single VPLS.
+
+   Untagged frame       Frame without an 802.1Q VLAN identifier.
+
+2.1.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+3.  Acronyms
+
+   AC            Attachment Circuit
+
+   BPDU          Bridge Protocol Data Unit
+
+   CE            Customer Edge device
+
+   FEC           Forwarding Equivalence Class
+
+   FIB           Forwarding Information Base
+
+   GRE           Generic Routing Encapsulation
+
+   IPsec         IP security
+
+   L2TP          Layer Two Tunneling Protocol
+
+   LAN           Local Area Network
+
+   LDP           Label Distribution Protocol
+
+   MTU-s         Multi-Tenant Unit switch
+
+   PE            Provider Edge device
+
+   PW            Pseudowire
+
+   STP           Spanning Tree Protocol
+
+
+
+
+Lasserre & Kompella         Standards Track                     [Page 4]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   VLAN          Virtual LAN
+
+   VLAN tag      VLAN Identifier
+
+4.  Topological Model for VPLS
+
+   An interface participating in a VPLS must be able to flood, forward,
+   and filter Ethernet frames.  Figure 1, below, shows the topological
+   model of a VPLS.  The set of PE devices interconnected via PWs
+   appears as a single emulated LAN to customer X.  Each PE will form
+   remote MAC address to PW associations and associate directly attached
+   MAC addresses to local customer facing ports.  This is modeled on
+   standard IEEE 802.1 MAC address learning.
+
+    +-----+                                              +-----+
+    | CE1 +---+      ...........................     +---| CE2 |
+    +-----+   |      .                         .     |   +-----+
+     Site 1   |   +----+                    +----+   |   Site 2
+              +---| PE |       Cloud        | PE |---+
+                  +----+                    +----+
+                     .                         .
+                     .         +----+          .
+                     ..........| PE |...........
+                               +----+         ^
+                                 |            |
+                                 |            +-- Emulated LAN
+                               +-----+
+                               | CE3 |
+                               +-----+
+                               Site 3
+
+               Figure 1: Topological Model of a VPLS for
+                      Customer X with three sites
+
+   We note here again that while this document shows specific examples
+   using MPLS transport tunnels, other tunnels that can be used by PWs
+   (as mentioned in [RFC4447]) -- e.g., GRE, L2TP, IPsec -- can also be
+   used, as long as the originating PE can be identified, since this is
+   used in the MAC learning process.
+
+   The scope of the VPLS lies within the PEs in the service provider
+   network, highlighting the fact that apart from customer service
+   delineation, the form of access to a customer site is not relevant to
+   the VPLS [L2VPN-REQ].  In other words, the attachment circuit (AC)
+   connected to the customer could be a physical Ethernet port, a
+   logical (tagged) Ethernet port, an ATM PVC carrying Ethernet frames,
+   etc., or even an Ethernet PW.
+
+
+
+
+Lasserre & Kompella         Standards Track                     [Page 5]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   The PE is typically an edge router capable of running the LDP
+   signaling protocol and/or routing protocols to set up PWs.  In
+   addition, it is capable of setting up transport tunnels to other PEs
+   and delivering traffic over PWs.
+
+4.1.  Flooding and Forwarding
+
+   One of attributes of an Ethernet service is that frames sent to
+   broadcast addresses and to unknown destination MAC addresses are
+   flooded to all ports.  To achieve flooding within the service
+   provider network, all unknown unicast, broadcast and multicast frames
+   are flooded over the corresponding PWs to all PE nodes participating
+   in the VPLS, as well as to all ACs.
+
+   Note that multicast frames are a special case and do not necessarily
+   have to be sent to all VPN members.  For simplicity, the default
+   approach of broadcasting multicast frames is used.
+
+   To forward a frame, a PE MUST be able to associate a destination MAC
+   address with a PW.  It is unreasonable and perhaps impossible to
+   require that PEs statically configure an association of every
+   possible destination MAC address with a PW.  Therefore, VPLS-capable
+   PEs SHOULD have the capability to dynamically learn MAC addresses on
+   both ACs and PWs and to forward and replicate packets across both ACs
+   and PWs.
+
+4.2.  Address Learning
+
+   Unlike BGP VPNs [RFC4364], reachability information is not advertised
+   and distributed via a control plane.  Reachability is obtained by
+   standard learning bridge functions in the data plane.
+
+   When a packet arrives on a PW, if the source MAC address is unknown,
+   it needs to be associated with the PW, so that outbound packets to
+   that MAC address can be delivered over the associated PW.  Likewise,
+   when a packet arrives on an AC, if the source MAC address is unknown,
+   it needs to be associated with the AC, so that outbound packets to
+   that MAC address can be delivered over the associated AC.
+
+   Standard learning, filtering, and forwarding actions, as defined in
+   [802.1D-ORIG], [802.1D-REV], and [802.1Q], are required when a PW or
+   AC state changes.
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                     [Page 6]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+4.3.  Tunnel Topology
+
+   PE routers are assumed to have the capability to establish transport
+   tunnels.  Tunnels are set up between PEs to aggregate traffic.  PWs
+   are signaled to demultiplex encapsulated Ethernet frames from
+   multiple VPLS instances that traverse the transport tunnels.
+
+   In an Ethernet L2VPN, it becomes the responsibility of the service
+   provider to create the loop-free topology.  For the sake of
+   simplicity, we define that the topology of a VPLS is a full mesh of
+   PWs.
+
+4.4.  Loop free VPLS
+
+   If the topology of the VPLS is not restricted to a full mesh, then it
+   may be that for two PEs not directly connected via PWs, they would
+   have to use an intermediary PE to relay packets.  This topology would
+   require the use of some loop-breaking protocol, like a spanning tree
+   protocol.
+
+   Instead, a full mesh of PWs is established between PEs.  Since every
+   PE is now directly connected to every other PE in the VPLS via a PW,
+   there is no longer any need to relay packets, and we can instantiate
+   a simpler loop-breaking rule: the "split horizon" rule, whereby a PE
+   MUST NOT forward traffic from one PW to another in the same VPLS
+   mesh.
+
+   Note that customers are allowed to run a Spanning Tree Protocol (STP)
+   (e.g., as defined in [802.1D-REV]), such as when a customer has "back
+   door" links used to provide redundancy in the case of a failure
+   within the VPLS.  In such a case, STP Bridge PDUs (BPDUs) are simply
+   tunneled through the provider cloud.
+
+5.  Discovery
+
+   The capability to manually configure the addresses of the remote PEs
+   is REQUIRED.  However, the use of manual configuration is not
+   necessary if an auto-discovery procedure is used.  A number of auto-
+   discovery procedures are compatible with this document
+   ([RADIUS-DISC], [BGP-DISC]).
+
+6.  Control Plane
+
+   This document describes the control plane functions of signaling of
+   PW labels.  Some foundational work in the area of support for multi-
+   homing is laid.  The extensions to provide multi-homing support
+   should work independently of the basic VPLS operation, and they are
+   not described here.
+
+
+
+Lasserre & Kompella         Standards Track                     [Page 7]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+6.1.  LDP-Based Signaling of Demultiplexers
+
+   A full mesh of LDP sessions is used to establish the mesh of PWs.
+   The requirement for a full mesh of PWs may result in a large number
+   of targeted LDP sessions.  Section 10 discusses the option of setting
+   up hierarchical topologies in order to minimize the size of the VPLS
+   full mesh.
+
+   Once an LDP session has been formed between two PEs, all PWs between
+   these two PEs are signaled over this session.
+
+   In [RFC4447], two types of FECs are described: the PWid FEC Element
+   (FEC type 128) and the Generalized PWid FEC Element (FEC type 129).
+   The original FEC element used for VPLS was compatible with the PWid
+   FEC Element.  The text for signaling using the PWid FEC Element has
+   been moved to Appendix A.  What we describe below replaces that with
+   a more generalized L2VPN descriptor, the Generalized PWid FEC
+   Element.
+
+6.1.1.  Using the Generalized PWid FEC Element
+
+   [RFC4447] describes a generalized FEC structure that is be used for
+   VPLS signaling in the following manner.  We describe the assignment
+   of the Generalized PWid FEC Element fields in the context of VPLS
+   signaling.
+
+   Control bit (C): This bit is used to signal the use of the control
+   word as specified in [RFC4447].
+
+   PW type: The allowed PW types are Ethernet (0x0005) and Ethernet
+   tagged mode (0x004), as specified in [RFC4446].
+
+   PW info length: As specified in [RFC4447].
+
+   Attachment Group Identifier (AGI), Length, Value: The unique name of
+   this VPLS.  The AGI identifies a type of name, and Length denotes the
+   length of Value, which is the name of the VPLS.  We use the term AGI
+   interchangeably with VPLS identifier.
+
+   Target Attachment Individual Identifier (TAII), Source Attachment
+   Individual Identifier (SAII): These are null because the mesh of PWs
+   in a VPLS terminates on MAC learning tables, rather than on
+   individual attachment circuits.  The use of non-null TAII and SAII is
+   reserved for future enhancements.
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                     [Page 8]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   Interface Parameters: The relevant interface parameters are:
+
+   -  MTU: The MTU (Maximum Transmission Unit) of the VPLS MUST be the
+      same across all the PWs in the mesh.
+
+   -  Optional Description String: Same as [RFC4447].
+
+   -  Requested VLAN ID: If the PW type is Ethernet tagged mode, this
+      parameter may be used to signal the insertion of the appropriate
+      VLAN ID, as defined in [RFC4448].
+
+6.2.  MAC Address Withdrawal
+
+   It MAY be desirable to remove or unlearn MAC addresses that have been
+   dynamically learned for faster convergence.  This is accomplished by
+   sending an LDP Address Withdraw Message with the list of MAC
+   addresses to be removed to all other PEs over the corresponding LDP
+   sessions.
+
+   We introduce an optional MAC List TLV in LDP to specify a list of MAC
+   addresses that can be removed or unlearned using the LDP Address
+   Withdraw Message.
+
+   The Address Withdraw message with MAC List TLVs MAY be supported in
+   order to expedite removal of MAC addresses as the result of a
+   topology change (e.g., failure of the primary link for a dual-homed
+   VPLS-capable switch).
+
+   In order to minimize the impact on LDP convergence time, when the MAC
+   list TLV contains a large number of MAC addresses, it may be
+   preferable to send a MAC address withdrawal message with an empty
+   list.
+
+6.2.1.  MAC List TLV
+
+   MAC addresses to be unlearned can be signaled using an LDP Address
+   Withdraw Message that contains a new TLV, the MAC List TLV.  Its
+   format is described below.  The encoding of a MAC List TLV address is
+   the 6-octet MAC address specified by IEEE 802 documents [802.1D-ORIG]
+   [802.1D-REV].
+
+
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                     [Page 9]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |U|F|       Type                |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      MAC address #1                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        MAC address #1         |      MAC Address #2           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      MAC address #2                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ~                              ...                              ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      MAC address #n                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        MAC address #n         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   U bit: Unknown bit.  This bit MUST be set to 1.  If the MAC address
+   format is not understood, then the TLV is not understood and MUST be
+   ignored.
+
+   F bit: Forward bit.  This bit MUST be set to 0.  Since the LDP
+   mechanism used here is targeted, the TLV MUST NOT be forwarded.
+
+   Type: Type field.  This field MUST be set to 0x0404.  This identifies
+   the TLV type as MAC List TLV.
+
+   Length: Length field.  This field specifies the total length in
+   octets of the MAC addresses in the TLV.  The length MUST be a
+   multiple of 6.
+
+   MAC Address: The MAC address(es) being removed.
+
+   The MAC Address Withdraw Message contains a FEC TLV (to identify the
+   VPLS affected), a MAC Address TLV, and optional parameters.  No
+   optional parameters have been defined for the MAC Address Withdraw
+   signaling.  Note that if a PE receives a MAC Address Withdraw Message
+   and does not understand it, it MUST ignore the message.  In this
+   case, instead of flushing its MAC address table, it will continue to
+   use stale information, unless:
+
+   -  it receives a packet with a known MAC address association, but
+      from a different PW, in which case it replaces the old
+      association; or
+
+   -  it ages out the old association.
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 10]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   The MAC Address Withdraw message only helps speed up convergence, so
+   PEs that do not understand the message can continue to participate in
+   the VPLS.
+
+6.2.2.  Address Withdraw Message Containing MAC List TLV
+
+   The processing for MAC List TLV received in an Address Withdraw
+   Message is:
+
+   For each MAC address in the TLV:
+
+   -  Remove the association between the MAC address and the AC or PW
+      over which this message is received.
+
+   For a MAC Address Withdraw message with empty list:
+
+   -  Remove all the MAC addresses associated with the VPLS instance
+      (specified by the FEC TLV) except the MAC addresses learned over
+      the PW associated with this signaling session over which the
+      message was received.
+
+   The scope of a MAC List TLV is the VPLS specified in the FEC TLV in
+   the MAC Address Withdraw Message.  The number of MAC addresses can be
+   deduced from the length field in the TLV.
+
+7.  Data Forwarding on an Ethernet PW
+
+   This section describes the data plane behavior on an Ethernet PW used
+   in a VPLS.  While the encapsulation is similar to that described in
+   [RFC4448], the functions of stripping the service-delimiting tag and
+   using a "normalized" Ethernet frame are described.
+
+7.1.  VPLS Encapsulation Actions
+
+   In a VPLS, a customer Ethernet frame without preamble is encapsulated
+   with a header as defined in [RFC4448].  A customer Ethernet frame is
+   defined as follows:
+
+   -  If the frame, as it arrives at the PE, has an encapsulation that
+      is used by the local PE as a service delimiter, i.e., to identify
+      the customer and/or the particular service of that customer, then
+      that encapsulation may be stripped before the frame is sent into
+      the VPLS.  As the frame exits the VPLS, the frame may have a
+      service-delimiting encapsulation inserted.
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 11]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   -  If the frame, as it arrives at the PE, has an encapsulation that
+      is not service delimiting, then it is a customer frame whose
+      encapsulation should not be modified by the VPLS.  This covers,
+      for example, a frame that carries customer-specific VLAN tags that
+      the service provider neither knows about nor wants to modify.
+
+   As an application of these rules, a customer frame may arrive at a
+   customer-facing port with a VLAN tag that identifies the customer's
+   VPLS instance.  That tag would be stripped before it is encapsulated
+   in the VPLS.  At egress, the frame may be tagged again, if a
+   service-delimiting tag is used, or it may be untagged if none is
+   used.
+
+   Likewise, if a customer frame arrives at a customer-facing port over
+   an ATM or Frame Relay VC that identifies the customer's VPLS
+   instance, then the ATM or FR encapsulation is removed before the
+   frame is passed into the VPLS.
+
+   Contrariwise, if a customer frame arrives at a customer-facing port
+   with a VLAN tag that identifies a VLAN domain in the customer L2
+   network, then the tag is not modified or stripped, as it belongs with
+   the rest of the customer frame.
+
+   By following the above rules, the Ethernet frame that traverses a
+   VPLS is always a customer Ethernet frame.  Note that the two actions,
+   at ingress and egress, of dealing with service delimiters are local
+   actions that neither PE has to signal to the other.  They allow, for
+   example, a mix-and-match of VLAN tagged and untagged services at
+   either end, and they do not carry across a VPLS a VLAN tag that has
+   local significance only.  The service delimiter may be an MPLS label
+   also, whereby an Ethernet PW given by [RFC4448] can serve as the
+   access side connection into a PE.  An RFC1483 Bridged PVC
+   encapsulation could also serve as a service delimiter.  By limiting
+   the scope of locally significant encapsulations to the edge,
+   hierarchical VPLS models can be developed that provide the capability
+   to network-engineer scalable VPLS deployments, as described below.
+
+7.2.  VPLS Learning Actions
+
+   Learning is done based on the customer Ethernet frame as defined
+   above.  The Forwarding Information Base (FIB) keeps track of the
+   mapping of customer Ethernet frame addressing and the appropriate PW
+   to use.  We define two modes of learning: qualified and unqualified
+   learning.  Qualified learning is the default mode and MUST be
+   supported.  Support of unqualified learning is OPTIONAL.
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 12]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   In unqualified learning, all the VLANs of a single customer are
+   handled by a single VPLS, which means they all share a single
+   broadcast domain and a single MAC address space.  This means that MAC
+   addresses need to be unique and non-overlapping among customer VLANs,
+   or else they cannot be differentiated within the VPLS instance, and
+   this can result in loss of customer frames.  An application of
+   unqualified learning is port-based VPLS service for a given customer
+   (e.g., customer with non-multiplexed AC where all the traffic on a
+   physical port, which may include multiple customer VLANs, is mapped
+   to a single VPLS instance).
+
+   In qualified learning, each customer VLAN is assigned to its own VPLS
+   instance, which means each customer VLAN has its own broadcast domain
+   and MAC address space.  Therefore, in qualified learning, MAC
+   addresses among customer VLANs may overlap with each other, but they
+   will be handled correctly since each customer VLAN has its own FIB;
+   i.e., each customer VLAN has its own MAC address space.  Since VPLS
+   broadcasts multicast frames by default, qualified learning offers the
+   advantage of limiting the broadcast scope to a given customer VLAN.
+   Qualified learning can result in large FIB table sizes, because the
+   logical MAC address is now a VLAN tag + MAC address.
+
+   For STP to work in qualified learning mode, a VPLS PE must be able to
+   forward STP BPDUs over the proper VPLS instance.  In a hierarchical
+   VPLS case (see details in Section 10), service delimiting tags
+   (Q-in-Q or [RFC4448]) can be added such that PEs can unambiguously
+   identify all customer traffic, including STP BPDUs.  In a basic VPLS
+   case, upstream switches must insert such service delimiting tags.
+   When an access port is shared among multiple customers, a reserved
+   VLAN per customer domain must be used to carry STP traffic.  The STP
+   frames are encapsulated with a unique provider tag per customer (as
+   the regular customer traffic), and a PEs looks up the provider tag to
+   send such frames across the proper VPLS instance.
+
+8.  Data Forwarding on an Ethernet VLAN PW
+
+   This section describes the data plane behavior on an Ethernet VLAN PW
+   in a VPLS.  While the encapsulation is similar to that described in
+   [RFC4448], the functions of imposing tags and using a "normalized"
+   Ethernet frame are described.  The learning behavior is the same as
+   for Ethernet PWs.
+
+8.1.  VPLS Encapsulation Actions
+
+   In a VPLS, a customer Ethernet frame without preamble is encapsulated
+   with a header as defined in [RFC4448].  A customer Ethernet frame is
+   defined as follows:
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 13]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   -  If the frame, as it arrives at the PE, has an encapsulation that
+      is part of the customer frame and is also used by the local PE as
+      a service delimiter, i.e., to identify the customer and/or the
+      particular service of that customer, then that encapsulation is
+      preserved as the frame is sent into the VPLS, unless the Requested
+      VLAN ID optional parameter was signaled.  In that case, the VLAN
+      tag is overwritten before the frame is sent out on the PW.
+
+   -  If the frame, as it arrives at the PE, has an encapsulation that
+      does not have the required VLAN tag, a null tag is imposed if the
+      Requested VLAN ID optional parameter was not signaled.
+
+   As an application of these rules, a customer frame may arrive at a
+   customer-facing port with a VLAN tag that identifies the customer's
+   VPLS instance and also identifies a customer VLAN.  That tag would be
+   preserved as it is encapsulated in the VPLS.
+
+   The Ethernet VLAN PW provides a simple way to preserve customer
+   802.1p bits.
+
+   A VPLS MAY have both Ethernet and Ethernet VLAN PWs.  However, if a
+   PE is not able to support both PWs simultaneously, it SHOULD send a
+   Label Release on the PW messages that it cannot support with a status
+   code "Unknown FEC" as given in [RFC3036].
+
+9.  Operation of a VPLS
+
+   We show here, in Figure 2, below, an example of how a VPLS works.
+   The following discussion uses the figure below, where a VPLS has been
+   set up between PE1, PE2, and PE3.  The VPLS connects a customer with
+   4 sites labeled A1, A2, A3, and A4 through CE1, CE2, CE3, and CE4,
+   respectively.
+
+   Initially, the VPLS is set up so that PE1, PE2, and PE3 have a full
+   mesh of Ethernet PWs.  The VPLS instance is assigned an identifier
+   (AGI).  For the above example, say PE1 signals PW label 102 to PE2
+   and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 14]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+                                                      -----
+                                                     /  A1 \
+        ----                                    ----CE1    |
+       /    \          --------       -------  /     |     |
+       | A2 CE2-      /        \     /       PE1     \     /
+       \    /   \    /          \---/         \       -----
+        ----     ---PE2                        |
+                    | Service Provider Network |
+                     \          /   \         /
+              -----  PE3       /     \       /
+              |Agg|_/  --------       -------
+             -|   |
+      ----  / -----  ----
+     /    \/    \   /    \             CE = Customer Edge Router
+     | A3 CE3    -CE4 A4 |             PE = Provider Edge Router
+     \    /         \    /             Agg = Layer 2 Aggregation
+      ----           ----
+
+                      Figure 2: Example of a VPLS
+
+   Assume a packet from A1 is bound for A2.  When it leaves CE1, say it
+   has a source MAC address of M1 and a destination MAC of M2.  If PE1
+   does not know where M2 is, it will flood the packet; i.e., send it to
+   PE2 and PE3.  When PE2 receives the packet, it will have a PW label
+   of 201.  PE2 can conclude that the source MAC address M1 is behind
+   PE1, since it distributed the label 201 to PE1.  It can therefore
+   associate MAC address M1 with PW label 102.
+
+9.1.  MAC Address Aging
+
+   PEs that learn remote MAC addresses SHOULD have an aging mechanism to
+   remove unused entries associated with a PW label.  This is important
+   both for conservation of memory and for administrative purposes.  For
+   example, if a customer site A, is shut down, eventually the other PEs
+   should unlearn A's MAC address.
+
+   The aging timer for MAC address M SHOULD be reset when a packet with
+   source MAC address M is received.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 15]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+10.  A Hierarchical VPLS Model
+
+   The solution described above requires a full mesh of tunnel LSPs
+   between all the PE routers that participate in the VPLS service.  For
+   each VPLS service, n*(n-1)/2 PWs must be set up between the PE
+   routers.  While this creates signaling overhead, the real detriment
+   to large scale deployment is the packet replication requirements for
+   each provisioned PWs on a PE router.  Hierarchical connectivity,
+   described in this document, reduces signaling and replication
+   overhead to allow large-scale deployment.
+
+   In many cases, service providers place smaller edge devices in
+   multi-tenant buildings and aggregate them into a PE in a large
+   Central Office (CO) facility.  In some instances, standard IEEE
+   802.1q (Dot 1Q) tagging techniques may be used to facilitate mapping
+   CE interfaces to VPLS access circuits at a PE.
+
+   It is often beneficial to extend the VPLS service tunneling
+   techniques into the access switch domain.  This can be accomplished
+   by treating the access device as a PE and provisioning PWs between it
+   and every other edge, as a basic VPLS.  An alternative is to utilize
+   [RFC4448] PWs or Q-in-Q logical interfaces between the access device
+   and selected VPLS enabled PE routers.  Q-in-Q encapsulation is
+   another form of L2 tunneling technique, which can be used in
+   conjunction with MPLS signaling, as will be described later.  The
+   following two sections focus on this alternative approach.  The VPLS
+   core PWs (hub) are augmented with access PWs (spoke) to form a two-
+   tier hierarchical VPLS (H-VPLS).
+
+   Spoke PWs may be implemented using any L2 tunneling mechanism, and by
+   expanding the scope of the first tier to include non-bridging VPLS PE
+   routers.  The non-bridging PE router would extend a spoke PW from a
+   Layer-2 switch that connects to it, through the service core network,
+   to a bridging VPLS PE router supporting hub PWs.  We also describe
+   how VPLS-challenged nodes and low-end CEs without MPLS capabilities
+   may participate in a hierarchical VPLS.
+
+   For rest of this discussion we refer to a bridging capable access
+   device as MTU-s and a non-bridging capable PE as PE-r.  We refer to a
+   routing and bridging capable device as PE-rs.
+
+10.1.  Hierarchical Connectivity
+
+   This section describes the hub and spoke connectivity model and
+   describes the requirements of the bridging capable and non-bridging
+   MTU-s devices for supporting the spoke connections.
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 16]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+10.1.1.  Spoke Connectivity for Bridging-Capable Devices
+
+   In Figure 3, below, three customer sites are connected to an MTU-s
+   through CE-1, CE-2, and CE-3.  The MTU-s has a single connection
+   (PW-1) to PE1-rs.  The PE-rs devices are connected in a basic VPLS
+   full mesh.  For each VPLS service, a single spoke PW is set up
+   between the MTU-s and the PE-rs based on [RFC4447].  Unlike
+   traditional PWs that terminate on a physical (or a VLAN-tagged
+   logical) port, a spoke PW terminates on a virtual switch instance
+   (VSI; see [L2FRAME]) on the MTU-s and the PE-rs devices.
+
+                                                          PE2-rs
+                                                        +--------+
+                                                        |        |
+                                                        |   --   |
+                                                        |  /  \  |
+    CE-1                                                |  \S /  |
+     \                                                  |   --   |
+      \                                                 +--------+
+       \   MTU-s                          PE1-rs        /   |
+        +--------+                      +--------+     /    |
+        |        |                      |        |    /     |
+        |   --   |      PW-1            |   --   |---/      |
+        |  /  \--|- - - - - - - - - - - |  /  \  |          |
+        |  \S /  |                      |  \S /  |          |
+        |   --   |                      |   --   |---\      |
+        +--------+                      +--------+    \     |
+         /                                             \    |
+       ----                                             +--------+
+      |Agg |                                            |        |
+       ----                                             |  --    |
+      /    \                                            | /  \   |
+     CE-2  CE-3                                         | \S /   |
+                                                        |  --    |
+                                                        +--------+
+                                                          PE3-rs
+    Agg = Layer-2 Aggregation
+    --
+   /  \
+   \S / = Virtual Switch Instance
+    --
+
+           Figure 3: An example of a hierarchical VPLS model
+
+   The MTU-s and the PE-rs treat each spoke connection like an AC of the
+   VPLS service.  The PW label is used to associate the traffic from the
+   spoke to a VPLS instance.
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 17]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+10.1.1.1.  MTU-s Operation
+
+   An MTU-s is defined as a device that supports layer-2 switching
+   functionality and does all the normal bridging functions of learning
+   and replication on all its ports, including the spoke, which is
+   treated as a virtual port.  Packets to unknown destinations are
+   replicated to all ports in the service including the spoke.  Once the
+   MAC address is learned, traffic between CE1 and CE2 will be switched
+   locally by the MTU-s, saving the capacity of the spoke to the PE-rs.
+   Similarly traffic between CE1 or CE2 and any remote destination is
+   switched directly onto the spoke and sent to the PE-rs over the
+   point-to-point PW.
+
+   Since the MTU-s is bridging capable, only a single PW is required per
+   VPLS instance for any number of access connections in the same VPLS
+   service.  This further reduces the signaling overhead between the
+   MTU-s and PE-rs.
+
+   If the MTU-s is directly connected to the PE-rs, other encapsulation
+   techniques, such as Q-in-Q, can be used for the spoke.
+
+10.1.1.2.  PE-rs Operation
+
+   A PE-rs is a device that supports all the bridging functions for VPLS
+   service and supports the routing and MPLS encapsulation; i.e., it
+   supports all the functions described for a basic VPLS, as described
+   above.
+
+   The operation of PE-rs is independent of the type of device at the
+   other end of the spoke.  Thus, the spoke from the MTU-s is treated as
+   a virtual port, and the PE-rs will switch traffic between the spoke
+   PW, hub PWs, and ACs once it has learned the MAC addresses.
+
+10.1.2.  Advantages of Spoke Connectivity
+
+   Spoke connectivity offers several scaling and operational advantages
+   for creating large-scale VPLS implementations, while retaining the
+   ability to offer all the functionality of the VPLS service.
+
+   -  Eliminates the need for a full mesh of tunnels and full mesh of
+      PWs per service between all devices participating in the VPLS
+      service.
+
+   -  Minimizes signaling overhead, since fewer PWs are required for the
+      VPLS service.
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 18]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   -  Segments VPLS nodal discovery.  MTU-s needs to be aware of only
+      the PE-rs node, although it is participating in the VPLS service
+      that spans multiple devices.  On the other hand, every VPLS PE-rs
+      must be aware of every other VPLS PE-rs and all of its locally
+      connected MTU-s and PE-r devices.
+
+   -  Addition of other sites requires configuration of the new MTU-s
+      but does not require any provisioning of the existing MTU-s
+      devices on that service.
+
+   -  Hierarchical connections can be used to create VPLS service that
+      spans multiple service provider domains.  This is explained in a
+      later section.
+
+   Note that as more devices participate in the VPLS, there are more
+   devices that require the capability for learning and replication.
+
+10.1.3.  Spoke Connectivity for Non-Bridging Devices
+
+   In some cases, a bridging PE-rs may not be deployed, or a PE-r might
+   already have been deployed.  In this section, we explain how a PE-r
+   that does not support any of the VPLS bridging functionality can
+   participate in the VPLS service.
+
+   In Figure 4, three customer sites are connected through CE-1, CE-2,
+   and CE-3 to the VPLS through PE-r.  For every attachment circuit that
+   participates in the VPLS service, PE-r creates a point-to-point PW
+   that terminates on the VSI of PE1-rs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 19]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+                                                         PE2-rs
+                                                       +--------+
+                                                       |        |
+                                                       |   --   |
+                                                       |  /  \  |
+   CE-1                                                |  \S /  |
+    \                                                  |   --   |
+     \                                                 +--------+
+      \   PE-r                           PE1-rs        /   |
+       +--------+                      +--------+     /    |
+       |\       |                      |        |    /     |
+       | \      |      PW-1            |   --   |---/      |
+       |  ------|- - - - - - - - - - - |  /  \  |          |
+       |   -----|- - - - - - - - - - - |  \S /  |          |
+       |  /     |                      |   --   |---\      |
+       +--------+                      +--------+    \     |
+        /                                             \    |
+      ----                                            +--------+
+     | Agg|                                           |        |
+      ----                                            |  --    |
+     /    \                                           | /  \   |
+    CE-2  CE-3                                        | \S /   |
+                                                      |  --    |
+                                                      +--------+
+                                                        PE3-rs
+
+              Figure 4: An example of a hierarchical VPLS
+                       with non-bridging spokes
+
+   The PE-r is defined as a device that supports routing but does not
+   support any bridging functions.  However, it is capable of setting up
+   PWs between itself and the PE-rs.  For every port that is supported
+   in the VPLS service, a PW is set up from the PE-r to the PE-rs.  Once
+   the PWs are set up, there is no learning or replication function
+   required on the part of the PE-r.  All traffic received on any of the
+   ACs is transmitted on the PW.  Similarly, all traffic received on a
+   PW is transmitted to the AC where the PW terminates.  Thus, traffic
+   from CE1 destined for CE2 is switched at PE1-rs and not at PE-r.
+
+   Note that in the case where PE-r devices use Provider VLANs (P-VLAN)
+   as demultiplexers instead of PWs, PE1-rs can treat them as such and
+   map these "circuits" into a VPLS domain to provide bridging support
+   between them.
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 20]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   This approach adds more overhead than the bridging-capable (MTU-s)
+   spoke approach, since a PW is required for every AC that participates
+   in the service versus a single PW required per service (regardless of
+   ACs) when an MTU-s is used.  However, this approach offers the
+   advantage of offering a VPLS service in conjunction with a routed
+   internet service without requiring the addition of new MTU-s.
+
+10.2.  Redundant Spoke Connections
+
+   An obvious weakness of the hub and spoke approach described thus far
+   is that the MTU-s has a single connection to the PE-rs.  In case of
+   failure of the connection or the PE-rs, the MTU-s suffers total loss
+   of connectivity.
+
+   In this section, we describe how the redundant connections can be
+   provided to avoid total loss of connectivity from the MTU-s.  The
+   mechanism described is identical for both, MTU-s and PE-r devices.
+
+10.2.1.  Dual-Homed MTU-s
+
+   To protect from connection failure of the PW or the failure of the
+   PE-rs, the MTU-s or the PE-r is dual-homed into two PE-rs devices.
+   The PE-rs devices must be part of the same VPLS service instance.
+
+   In Figure 5, two customer sites are connected through CE-1 and CE-2
+   to an MTU-s.  The MTU-s sets up two PWs (one each to PE1-rs and
+   PE3-rs) for each VPLS instance.  One of the two PWs is designated as
+   primary and is the one that is actively used under normal conditions,
+   whereas the second PW is designated as secondary and is held in a
+   standby state.  The MTU-s negotiates the PW labels for both the
+   primary and secondary PWs, but does not use the secondary PW unless
+   the primary PW fails.  How a spoke is designated primary or secondary
+   is outside the scope of this document.  For example, a spanning tree
+   instance running between only the MTU-s and the two PE-rs nodes is
+   one possible method.  Another method could be configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 21]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+                                                         PE2-rs
+                                                       +--------+
+                                                       |        |
+                                                       |   --   |
+                                                       |  /  \  |
+   CE-1                                                |  \S /  |
+     \                                                 |   --   |
+      \                                                +--------+
+       \  MTU-s                          PE1-rs        /   |
+       +--------+                      +--------+     /    |
+       |        |                      |        |    /     |
+       |   --   |   Primary PW         |   --   |---/      |
+       |  /  \  |- - - - - - - - - - - |  /  \  |          |
+       |  \S /  |                      |  \S /  |          |
+       |   --   |                      |   --   |---\      |
+       +--------+                      +--------+    \     |
+         /      \                                     \    |
+        /        \                                     +--------+
+       /          \                                    |        |
+      CE-2         \                                   |  --    |
+                    \     Secondary PW                 | /  \   |
+                     - - - - - - - - - - - - - - - - - | \S /   |
+                                                       |  --    |
+                                                       +--------+
+                                                         PE3-rs
+              Figure 5: An example of a dual-homed MTU-s
+
+10.2.2.  Failure Detection and Recovery
+
+   The MTU-s should control the usage of the spokes to the PE-rs
+   devices.  If the spokes are PWs, then LDP signaling is used to
+   negotiate the PW labels, and the hello messages used for the LDP
+   session could be used to detect failure of the primary PW.  The use
+   of other mechanisms that could provide faster detection failures is
+   outside the scope of this document.
+
+   Upon failure of the primary PW, MTU-s immediately switches to the
+   secondary PW.  At this point, the PE3-rs that terminates the
+   secondary PW starts learning MAC addresses on the spoke PW.  All
+   other PE-rs nodes in the network think that CE-1 and CE-2 are behind
+   PE1-rs and may continue to send traffic to PE1-rs until they learn
+   that the devices are now behind PE3-rs.  The unlearning process can
+   take a long time and may adversely affect the connectivity of
+   higher-level protocols from CE1 and CE2.  To enable faster
+   convergence, the PE3-rs where the secondary PW got activated may send
+   out a flush message (as explained in Section 6.2), using the MAC List
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 22]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   TLV, as defined in Section 6, to all PE-rs nodes.  Upon receiving the
+   message, PE-rs nodes flush the MAC addresses associated with that
+   VPLS instance.
+
+10.3.  Multi-domain VPLS Service
+
+   Hierarchy can also be used to create a large-scale VPLS service
+   within a single domain or a service that spans multiple domains
+   without requiring full mesh connectivity between all VPLS-capable
+   devices.  Two fully meshed VPLS networks are connected together using
+   a single LSP tunnel between the VPLS "border" devices.  A single
+   spoke PW per VPLS service is set up to connect the two domains
+   together.
+
+   When more than two domains need to be connected, a full mesh of
+   inter-domain spokes is created between border PEs.  Forwarding rules
+   over this mesh are identical to the rules defined in Section 4.
+
+   This creates a three-tier hierarchical model that consists of a hub-
+   and-spoke topology between MTU-s and PE-rs devices, a full-mesh
+   topology between PE-rs, and a full mesh of inter-domain spokes
+   between border PE-rs devices.
+
+   This document does not specify how redundant border PEs per domain
+   per VPLS instance can be supported.
+
+11.  Hierarchical VPLS Model Using Ethernet Access Network
+
+   In this section, the hierarchical model is expanded to include an
+   Ethernet access network.  This model retains the hierarchical
+   architecture discussed previously in that it leverages the full-mesh
+   topology among PE-rs devices; however, no restriction is imposed on
+   the topology of the Ethernet access network (e.g., the topology
+   between MTU-s and PE-rs devices is not restricted to hub and spoke).
+
+   The motivation for an Ethernet access network is that Ethernet-based
+   networks are currently deployed by some service providers to offer
+   VPLS services to their customers.  Therefore, it is important to
+   provide a mechanism that allows these networks to integrate with an
+   IP or MPLS core to provide scalable VPLS services.
+
+   One approach of tunneling a customer's Ethernet traffic via an
+   Ethernet access network is to add an additional VLAN tag to the
+   customer's data (which may be either tagged or untagged).  The
+   additional tag is referred to as Provider's VLAN (P-VLAN).  Inside
+   the provider's network each P-VLAN designates a customer or more
+   specifically a VPLS instance for that customer.  Therefore, there is
+   a one-to-one correspondence between a P-VLAN and a VPLS instance.  In
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 23]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   this model, the MTU-s needs to have the capability of adding the
+   additional P-VLAN tag to non-multiplexed ACs where customer VLANs are
+   not used as service delimiters.  This functionality is described in
+   [802.1ad].
+
+   If customer VLANs need to be treated as service delimiters (e.g., the
+   AC is a multiplexed port), then the MTU-s needs to have the
+   additional capability of translating a customer VLAN (C-VLAN) to a
+   P-VLAN, or to push an additional P-VLAN tag, in order to resolve
+   overlapping VLAN tags used by different customers.  Therefore, the
+   MTU-s in this model can be considered a typical bridge with this
+   additional capability.  This functionality is described in [802.1ad].
+
+   The PE-rs needs to be able to perform bridging functionality over the
+   standard Ethernet ports toward the access network, as well as over
+   the PWs toward the network core.  In this model, the PE-rs may need
+   to run STP towards the access network, in addition to split-horizon
+   over the MPLS core.  The PE-rs needs to map a P-VLAN to a VPLS-
+   instance and its associated PWs, and vice versa.
+
+   The details regarding bridge operation for MTU-s and PE-rs (e.g.,
+   encapsulation format for Q-in-Q messages, customer's Ethernet control
+   protocol handling, etc.) are outside the scope of this document and
+   are covered in [802.1ad].  However, the relevant part is the
+   interaction between the bridge module and the MPLS/IP PWs in the
+   PE-rs, which behaves just as in a regular VPLS.
+
+11.1.  Scalability
+
+   Since each P-VLAN corresponds to a VPLS instance, the total number of
+   VPLS instances supported is limited to 4K.  The P-VLAN serves as a
+   local service delimiter within the provider's network that is
+   stripped as it gets mapped to a PW in a VPLS instance.  Therefore,
+   the 4K limit applies only within an Ethernet access network (Ethernet
+   island) and not to the entire network.  The SP network consists of a
+   core MPLS/IP network that connects many Ethernet islands.  Therefore,
+   the number of VPLS instances can scale accordingly with the number of
+   Ethernet islands (a metro region can be represented by one or more
+   islands).
+
+11.2.  Dual Homing and Failure Recovery
+
+   In this model, an MTU-s can be dual homed to different devices
+   (aggregators and/or PE-rs devices).  The failure protection for
+   access network nodes and links can be provided through running STP in
+   each island.  The STP of each island is independent of other islands
+   and do not interact with others.  If an island has more than one
+   PE-rs, then a dedicated full-mesh of PWs is used among these PE-rs
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 24]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   devices for carrying the SP BPDU packets for that island.  On a
+   per-P-VLAN basis, STP will designate a single PE-rs to be used for
+   carrying the traffic across the core.  The loop-free protection
+   through the core is performed using split-horizon, and the failure
+   protection in the core is performed through standard IP/MPLS re-
+   routing.
+
+12.  Contributors
+
+   Loa Andersson, TLA
+   Ron Haberman, Alcatel-Lucent
+   Juha Heinanen, Independent
+   Giles Heron, Tellabs
+   Sunil Khandekar, Alcatel-Lucent
+   Luca Martini, Cisco
+   Pascal Menezes, Independent
+   Rob Nath, Alcatel-Lucent
+   Eric Puetz, AT&T
+   Vasile Radoaca, Independent
+   Ali Sajassi, Cisco
+   Yetik Serbest, AT&T
+   Nick Slabakov, Juniper
+   Andrew Smith, Consultant
+   Tom Soon, AT&T
+   Nick Tingle, Alcatel-Lucent
+
+13.  Acknowledgments
+
+   We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel
+   Halpern, Bill Hong, Rick Wilder, Jim Guichard, Steve Phillips, Norm
+   Finn, Matt Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen,
+   Yakov Rekhter, Sasha Vainshtein, and Du Wenhua for their valuable
+   feedback.
+
+   We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu
+   (Ixia), and Charlie Hundall for identifying issues with the draft in
+   the course of the interoperability tests.
+
+   We would also like to thank Ina Minei, Bob Thomas, Eric Gray and
+   Dimitri Papadimitriou for their thorough technical review of the
+   document.
+
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 25]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+14.  Security Considerations
+
+   A more comprehensive description of the security issues involved in
+   L2VPNs is covered in [RFC4111].  An unguarded VPLS service is
+   vulnerable to some security issues that pose risks to the customer
+   and provider networks.  Most of the security issues can be avoided
+   through implementation of appropriate guards.  A couple of them can
+   be prevented through existing protocols.
+
+   -  Data plane aspects
+
+        -  Traffic isolation between VPLS domains is guaranteed by the
+           use of per VPLS L2 FIB table and the use of per VPLS PWs.
+
+        -  The customer traffic, which consists of Ethernet frames, is
+           carried unchanged over VPLS.  If security is required, the
+           customer traffic SHOULD be encrypted and/or authenticated
+           before entering the service provider network.
+
+        -  Preventing broadcast storms can be achieved by using routers
+           as CPE devices or by rate policing the amount of broadcast
+           traffic that customers can send.
+
+   -  Control plane aspects
+
+        -  LDP security (authentication) methods as described in
+           [RFC3036] SHOULD be applied.  This would prevent
+           unauthenticated messages from disrupting a PE in a VPLS.
+
+   -  Denial of service attacks
+
+        -  Some means to limit the number of MAC addresses (per site per
+           VPLS) that a PE can learn SHOULD be implemented.
+
+15.  IANA Considerations
+
+   The type field in the MAC List TLV is defined as 0x404 in Section
+   6.2.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 26]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+16.  References
+
+16.1.  Normative References
+
+   [RFC4447]      Martini, L., Rosen, E., El-Aawar, N., Smith, T., and
+                  G. Heron, "Pseudowire Setup and Maintenance Using the
+                  Label Distribution Protocol (LDP)", RFC 4447, April
+                  2006.
+
+   [RFC4448]      Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
+                  "Encapsulation Methods for Transport of Ethernet over
+                  MPLS Networks", RFC 4448, April 2006.
+
+   [802.1D-ORIG]  Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std
+                  802.1D-1993 "MAC Bridges".
+
+   [802.1D-REV]   802.1D - "Information technology - Telecommunications
+                  and information exchange between systems - Local and
+                  metropolitan area networks - Common specifications -
+                  Part 3: Media Access Control (MAC) Bridges: Revision.
+                  This is a revision of ISO/IEC 10038: 1993, 802.1j-1992
+                  and 802.6k-1992.  It incorporates P802.11c, P802.1p
+                  and P802.12e." ISO/IEC 15802-3: 1998.
+
+   [802.1Q]       802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE
+                  Standards for Local and Metropolitan Area Networks:
+                  Virtual Bridged Local Area Networks", July 1998.
+
+   [RFC3036]      Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
+                  and B. Thomas, "LDP Specification", RFC 3036, January
+                  2001.
+
+   [RFC4446]      Martini, L., "IANA Allocations for Pseudowire Edge to
+                  Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+16.2.  Informative References
+
+   [RFC4364]      Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+                  Networks (VPNs)", RFC 4364, February 2006.
+
+   [RADIUS-DISC]  Heinanen, J., Weber, G., Ed., Townsley, W., Booth, S.,
+                  and W. Luo, "Using Radius for PE-Based VPN Discovery",
+                  Work in Progress, October 2005.
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 27]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+   [BGP-DISC]     Ould-Brahim, H., Ed., Rosen, E., Ed., and Y. Rekhter,
+                  Ed., "Using BGP as an Auto-Discovery Mechanism for
+                  Network-based VPNs", Work in Progress, September 2006.
+
+   [L2FRAME]      Andersson, L. and E. Rosen, "Framework for Layer 2
+                  Virtual Private Networks (L2VPNs)", RFC 4664,
+                  September 2006.
+
+   [L2VPN-REQ]    Augustyn, W. and Y. Serbest, "Service Requirements for
+                  Layer 2 Provider-Provisioned Virtual Private
+                  Networks", RFC 4665, September 2006.
+
+   [RFC4111]      Fang, L., "Security Framework for Provider-Provisioned
+                  Virtual Private Networks (PPVPNs)", RFC 4111, July
+                  2005.
+
+   [802.1ad]      "IEEE standard for Provider Bridges", Work in
+                  Progress, December 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 28]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+Appendix A.  VPLS Signaling using the PWid FEC Element
+
+   This section is being retained because live deployments use this
+   version of the signaling for VPLS.
+
+   The VPLS signaling information is carried in a Label Mapping message
+   sent in downstream unsolicited mode, which contains the following
+   PWid FEC TLV.
+
+   PW, C, PW Info Length, Group ID, and Interface parameters are as
+   defined in [RFC4447].
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |    PW TLV     |C|         PW Type             |PW info Length |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |                      Group ID                                 |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |                        PWID                                   |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |                       Interface parameters                    |
+  ~                                                               ~
+  |                                                               |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   We use the Ethernet PW type to identify PWs that carry Ethernet
+   traffic for multipoint connectivity.
+
+   In a VPLS, we use a VCID (which, when using the PWid FEC, has been
+   substituted with a more general identifier (AGI), to address
+   extending the scope of a VPLS) to identify an emulated LAN segment.
+   Note that the VCID as specified in [RFC4447] is a service identifier,
+   identifying a service emulating a point-to-point virtual circuit.  In
+   a VPLS, the VCID is a single service identifier, so it has global
+   significance across all PEs involved in the VPLS instance.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 29]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+Authors' Addresses
+
+   Marc Lasserre
+   Alcatel-Lucent
+   EMail: mlasserre@alcatel-lucent.com
+
+   Vach Kompella
+   Alcatel-Lucent
+   EMail: vach.kompella@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 30]
+
+RFC 4762          Virtual Private LAN Service over LDP      January 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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 currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Lasserre & Kompella         Standards Track                    [Page 31]
+