[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

   Internet Draft Document                              Marc Lasserre
   Provider Provisioned VPN Working Group         Riverstone Networks
   draft-lasserre-vkompella-ppvpn-vpls-03.txt           Vach Kompella
                                                           Nick Tingle
                                                       Sunil Khandekar
                                                     Timetra Networks
  
                                                          Ali Sajassi
                                                         Cisco Systems
  
   Pascal Menezes                                       Loa Andersson
   Terabeam Networks                                           Utfors
  
   Andrew Smith                                            Pierre Lin
   Consultant                                     Yipes Communication
  
   Juha Heinanen                                          Giles Heron
   Song Networks                                  PacketExchange Ltd.
  
   Ron Haberman                                         Tom S.C. Soon
   Masergy, Inc.                                        Yetik Serbest
                                                           Eric Puetz
   Nick Slabakov                                   SBC Communications
   Rob Nath
   Riverstone Networks
                                                         Luca Martini
   Vasile Radaoca                                             Level 3
   Nortel Networks                                     Communications
  
   Expires: July 2003                                    January 2003
  
  
                  Virtual Private LAN Services over MPLS
                draft-lasserre-vkompella-ppvpn-vpls-03.txt
  
   1.  Status of this Memo
  
   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.
  
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
  
   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."
  
   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
  
  
   Lasserre, Kompella et al.                                  [Page 1]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.
  
   2.  Abstract
  
   This document describes a  virtual private LAN service (VPLS)
   solution over MPLS, also known as Transparent LAN Services (TLS). A
   VPLS creates an emulated LAN segment for a given set of users.  It
   delivers a layer 2 broadcast domain that is fully capable of
   learning and forwarding on Ethernet MAC addresses that is closed to
   a given set of users.  Many VPLS services can be supported from a
   single PE node.
  
   This document describes the control plane functions of signaling
   demultiplexor labels, extending [PWE3-CTRL] and rudimentary support
   for availability (multi-homing).  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 [PWE3-
   ETHERNET].
  
   3.  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
  
   Placement of this Memo in Sub-IP Area
  
   RELATED DOCUMENTS
  
   www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-requirements-
   01.txt
   www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-01.txt
   www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-01.txt
  
   WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK
  
   PPVPN
  
   WHY IS IT TARGETED AT THIS WG
  
   The charter of the PPVPN WG includes L2 VPN services and this draft
   specifies a model for Ethernet L2 VPN services over MPLS.
  
   JUSTIFICATION
  
   Existing Internet drafts specify how to provide point-to-point
   Ethernet L2 VPN services over MPLS. This draft defines how
   multipoint Ethernet services can be provided.
  
  
  
   Lasserre, Kompella et al.                                  [Page 2]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   Table of Contents
  
   1. Status of this Memo.............................................1
   2. Abstract........................................................2
   3. Conventions.....................................................2
   4. Overview........................................................4
   5. Topological Model for VPLS......................................5
   5.1. Flooding and Forwarding.......................................5
   5.2. Address Learning..............................................6
   5.3. LSP Topology..................................................6
   5.4. Loop free L2 VPN..............................................7
   6. Discovery.......................................................7
   7. Control Plane...................................................7
   7.1. LDP Based Signaling of Demultiplexors.........................7
   7.2. MAC Address Withdrawal........................................9
   7.2.1. MAC TLV.....................................................9
   7.2.2. Address Withdraw Message Containing MAC TLV................10
   8. Data Forwarding on an Ethernet VPLS VC Type....................11
   8.1. VPLS Encapsulation actions...................................11
   8.1.1. VPLS Learning actions......................................12
   9. Operation of a VPLS............................................12
   9.1. MAC Address Aging............................................13
   10. A Hierarchical VPLS Model.....................................13
   10.1. Hierarchical connectivity...................................14
   10.1.1. Spoke connectivity for bridging-capable devices...........14
   10.1.2. Advantages of spoke connectivity..........................16
   10.1.3. Spoke connectivity for non-bridging devices...............17
   10.2. Redundant Spoke Connections.................................18
   10.2.1. Dual-homed MTU device.....................................18
   10.2.2. Failure detection and recovery............................19
   10.3. Multi-domain VPLS service...................................20
   11. Hierarchical VPLS model using Ethernet Access Network.........20
   11.1. Port-based v.s. VLAN-based VPLS operation...................22
   12. Significant Modifications.....................................23
   13. Acknowledgments...............................................23
   14. Security Considerations.......................................24
   15. Intellectual Property Considerations..........................24
   16. Full Copyright Statement......................................24
   17. References....................................................24
   18. Authors' Addresses............................................25
  
  
  
  
  
  
  
   Lasserre, Kompella et al.                                  [Page 3]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   4.  Overview
  
   Ethernet has become the predominant technology for Local Area
   Networks (LANs) connectivity and is gaining acceptance as an access
   technology, specifically in Metropolitan and Wide Area Networks (MAN
   and WAN respectively). An Ethernet port is used to connect a
   customer to the Provider Edge (PE) router acting as an LER. Customer
   traffic is subsequently mapped to a specific MPLS L2 VPN by
   configuring L2 FECs based upon the input port ID and/or VLAN tag
   depending upon the VPLS service.
  
   Broadcast and multicast services are available over traditional
   LANs. MPLS does not support such services currently. 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 LSP basis, packet replication across LSPs
   for multicast/broadcast traffic and for flooding of unknown unicast
   destination traffic.
  
   The primary motivation behind Virtual Private LAN Services (VPLS) is
   to provide connectivity between geographically dispersed customer
   sites across MAN/WAN network(s), 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
  
   [PWE3-ETHERNET] defines how to carry L2 PDUs over point-to-point
   MPLS LSPs, called VC LSPs. Such VC LSPs can be carried over MPLS or
   GRE tunnels. This document describes extensions to [PWE3-CTRL] 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 serve as Label Edge
   Routers (LERs) on an MPLS network that is VPLS capable. The behavior
   of transit Label Switch Routers (LSRs) that are considered a part of
   MPLS network is not discussed. The MPLS network provides a number of
   Label Switch Paths (LSPs) that form the basis for connections
   between LERs attached to the same MPLS network. The resulting set of
   interconnected LERs forms a private MPLS VPN where each LSP is
   uniquely identified at each MPLS interface by a label.
  
  
   Lasserre, Kompella et al.                                  [Page 4]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
  
   5.  Topological Model for VPLS
  
   An interface participating in a VPLS must be able to flood, forward,
   and filter ethernet frames.
  
   +----+                                              +----+
   + C1 +---+      ...........................     +---| C1 |
   +----+   |      .                         .     |   +----+
   Site A   |   +----+                    +----+   |   Site B
            +---| PE |---- MPLS Cloud ----| PE |---+
                +----+         |          +----+
                   .           |             .
                   .         +----+          .
                   ..........| PE |...........
                             +----+         ^
                               |            |
                               |            +-- Emulated VLAN
                             +----+
                             | C1 |
                             +----+
                             Site C
  
   The set of PE devices interconnected via transport tunnels appears
   as a single emulated VLAN to customer C1. Each PE device will learn
   remote MAC addresses to VC LSP associations and learns directly
   attached MAC addresses on customer facing ports.
  
   We note here that while this document shows specific examples using
   MPLS transport tunnels, other tunnels that can be used by pseudo-
   wires, e.g., GRE, L2TP, IPSEC, etc., 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 [VPLS-REQ].
  
   The PE device is typically an edge router capable of running a
   signaling protocol and/or routing protocols to exchange VC label
   information.  In addition, it is capable of setting up transport
   tunnels to other PEs to deliver VC LSP traffic.
  
  
   5.1.  Flooding and Forwarding
  
   One of attributes of an Ethernet service is that all broadcast and
   destination unknown MAC addresses are flooded to all ports. To
   achieve flooding within the service provider network, all address
   unknown unicast, broadcast and multicast frames are flooded over the
  
  
   Lasserre, Kompella et al.                                  [Page 5]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   corresponding pseudowires to all relevant PE nodes participating in
   the VPLS.
  
   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 can be used. Extensions
   explaining how to interact with 802.1 GMRP protocol, IGMP snooping
   and static MAC multicast filters will be discussed in a future
   revision if needed.
  
   To forward a frame, a PE must be able to associate a destination MAC
   address with a VC LSP. It is unreasonable and perhaps impossible to
   require PEs to statically configure an association of every possible
   destination MAC address with a VC LSP. Therefore, VPLS-capable PEs
   must have the capability to dynamically learn MAC addresses on both
   physical ports and virtual circuits and to forward and replicate
   packets across both physical ports and virtual circuits.
  
  
   5.2.  Address Learning
  
   Unlike BGP VPNs [BGP-VPN], reachability information does not need to
   be advertised and distributed via a control plane.  Reachability is
   obtained by standard learning bridge functions in the data plane.
  
   As discussed previously, a pseudowire consists of a pair of uni-
   directional VC LSPs. When a new MAC address is learned on an inbound
   VC LSP, it needs to be associated with the outbound VC LSP that is
   part of the same pair. The state of this logical link can be
   considered as up as soon as both incoming and outgoing LSPs are
   established. Similarly, it can be considered as down as soon as one
   of these two LSPs is torn down.
  
   Standard learning, filtering and forwarding actions, as defined in
   [802.1D-ORIG], [802.1D-REV] and [802.1Q], are required when a
   logical link state changes.
  
  
   5.3.  LSP Topology
  
   PE routers typically run an IGP between them, and are assumed to
   have the capability to establish MPLS tunnels.  Tunnel LSPs are set
   up between PEs to aggregate traffic.  VC LSPs are signaled to
   demultiplex the L2 encapsulated packets that traverse the tunnel
   LSPs.
  
   In an Ethernet L2VPN, it becomes the responsibility of the service
   provider to create the loop free topology. For the sake of
   simplicity, we assume that the topology of a VPLS is a full mesh of
   tunnel and pseudowires.
  
  
  
   Lasserre, Kompella et al.                                  [Page 6]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
  
   5.4.  Loop free L2 VPN
  
   For simplicity, a full mesh of pseudowires is established between
   PEs. Ethernet bridges, unlike Frame Relay or ATM where the
   termination point becomes the CE node, has to examine the layer 2
   fields of the packets to make a switching decision. If the frame is
   a destination unknown, broadcast or multicast frame the frame must
   be flooded.
  
   Therefore, if the topology isn't a full mesh, the PE devices may
   need to forward these frames to other PEs. However, this would
   require the use of spanning tree protocol to form a loop free
   topology, that may have characteristics that are undesirable to the
   provider. The use of a full mesh and split-horizon forwarding
   obviates the need for a spanning tree protocol.
  
   Each PE MUST create a rooted tree to every other PE router that
   serve the same L2 VPN. Each PE MUST support a "split-horizon" scheme
   in order to prevent loops, that is, a PE MUST NOT forward traffic
   from one pseudowire to another in the same VPN (since each PE has
   direct connectivity to all other PEs in the same VPN).
  
   Note that customers are allowed to run STP 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 BPDUs are simply
   tunneled through the MPLS cloud.
  
   6.  Discovery
  
   Currently, no discovery mechanism has been prescribed for VPLS.
   There are three potential candidates, [BGP-DISC], [DNS-DISC], [LDP-
   DISC].
  
   7.  Control Plane
  
   This document describes the control plane functions of Demultiplexor
   Exchange (signaling of VC labels).  Some foundational work in the
   area of support for multi-homing is laid, although that work is
   described in a different document [VPLS-BRIDGING].
  
   7.1.  LDP Based Signaling of Demultiplexors
  
   In order to establish a full mesh of pseudowires, all PEs in a VPLS
   must have a full mesh of LDP sessions.
  
   Once an LDP session has been formed between two PEs, all pseudowires
   are signaled over this session.
  
   In [PWE3-CTRL], the L2 VPN information is carried in a Label Mapping
   message sent in downstream unsolicited mode, which contains the
  
  
   Lasserre, Kompella et al.                                  [Page 7]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   following VC FEC TLV.  VC, C, VC Info Length, Group ID, Interface
   parameters are as defined in [PWE3-CTRL].
  
  
  
  
  
    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    VC tlv     |C|         VC Type             |VC info Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Group ID                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        VC ID                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Interface parameters                    |
    |                              "                                |
    |                              "                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  
   This document defines a new VC type value in addition to the
   following values already defined in [PWE3-CTRL]:
  
   VC Type  Description
  
   0x0001   Frame Relay DLCI
   0x0002   ATM AAL5 VCC transport
   0x0003   ATM transparent cell transport
   0x0004   Ethernet VLAN
   0x0005   Ethernet
   0x0006   HDLC
   0x0007   PPP
   0x8008   CEM [8]
   0x0009   ATM VCC cell transport
   0x000A   ATM VPC cell transport
   0x000B   Ethernet VPLS
  
   VC types 0x0004 and 0x0005 identify VC LSPs that carry VLAN tagged
   and untagged Ethernet traffic respectively, for point-to-point
   connectivity.
  
   We define a new VC type, Ethernet VPLS, with codepoint 0x000B to
   identify VC LSPs that carry Ethernet traffic for multipoint
   connectivity.  The Ethernet VC Type is described below.
   For VC types 0x0001 to 0x000A, The VC ID identifies a particular VC.
   For the VPLS VC type, the VC ID is a VPN identifier globally unique
   within a service provider domain.
  
  
  
  
   Lasserre, Kompella et al.                                  [Page 8]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   Note that the VCID as specified in [PWE3-CTRL] is a service
   identifier, identifying a service emulating a point-to-point virtual
   circuit.  In a VPLS, the VCID is a single service identifier,
   identifying an emulated LAN segment.
  
   The use of the VCID as the VPN-id creates some challenges for inter-
   provider VPLS service and this issue will be addressed in the future
   revision.
  
   7.2.  MAC Address Withdrawal
  
   It MAY be desirable to remove or relearn MAC addresses that have
   been dynamically learned for faster convergence.
  
   We introduce an optional MAC TLV that is used to specify a list of
   MAC addresses that can be removed or relearned using the Address
   Withdraw Message.
  
   The Address Withdraw message with MAC TLVs MAY be supported in order
   to expedite learning of MAC addresses as the result of a topology
   change (e.g., failure of the primary link for a dual-homed MTU-s).
   If a notification message is sent on the backup link (blocked link),
   which has transitioned into an active state (e.g., similar to
   Topology Change Notification message of 802.1w RSTP), with a list of
   MAC entries to be relearned,  the PE will update the MAC entries in
   its FIB for that VPLS instance and send the message to other PEs
   over the corresponding directed LDP sessions.
  
   If the notification message contains an empty list, this tells the
   receiving PE to remove all the MAC addresses learned for the
   specified VPLS instance except the ones it learned from the sending
   PE (MAC address removal is required for all VPLS instances that are
   affected).  Note that the definition of such a notification message
   is outside the scope of the document, unless it happens to come from
   an MTU connected to the PE as a spoke.  In such a scenario, the
   message will be just an Address Withdraw message as noted above.
  
   7.2.1.  MAC TLV
  
   MAC addresses to be relearned can be signaled using an LDP Address
   Withdraw Message that contains a new TLV, the MAC TLV.  Its format
   is described below.  The encoding of a MAC TLV address is the 6-byte
   MAC address specified by IEEE 802 documents [g-ORIG] [802.1D-REV].
  
     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                           |
  
  
   Lasserre, Kompella et al.                                  [Page 9]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      MAC address #n                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
   U bit
        Unknown bit.  This bit MUST be set to 0.  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 (subject to IANA
   approval).  This identifies the TLV type as MAC TLV.
  
   Length
        Length field.  This field specifies the total length of the
   TLV, including the Type and Length fields.
  
   MAC Address
        The MAC address being removed.
  
   The LDP Address Withdraw Message contains a FEC TLV (to identify the
   VPLS in consideration), a MAC Address TLV and optional parameters.
   No optional parameters have been defined for the MAC Address
   Withdraw signaling.
  
   7.2.2.  Address Withdraw Message Containing MAC TLV
  
   When MAC addresses are being removed or relearned explicitly, e.g.,
   the primary link of a dual-homed MTU-s has failed, an Address
   Withdraw Message can be sent with the list of MAC addresses to be
   relearned.
  
   The processing for MAC TLVs received in an Address Withdraw Message
   is:
     For each MAC address in the TLV:
     - Relearn the association between the MAC address and the
        interface/pseudowire over which this message is received
     - Send the same message to all other PEs over the corresponding
        directed LDP sessions.
  
     For an 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
  
  
  
  
   Lasserre, Kompella et al.                                 [Page 10]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
        over this link (over the pseudowire associated with the
        signaling link over which the message is received)
     - Send the same message to all other PEs over the corresponding
        directed LDP sessions.
  
   The scope of a MAC TLV is the VPLS specified in the FEC TLV in the
   Address Withdraw Message.  The number of MAC addresses can be
   deduced from the length field in the TLV.
  
   Further descriptions of how to deal with failures expeditiously with
   different configurations will be described in other documents, such
   as [VPLS-BRIDGING].
  
   8.  Data Forwarding on an Ethernet VPLS VC Type
  
   This section describes the dataplane behavior on an Ethernet VPLS VC
   LSP.  While the encapsulation is similar to that described in [PWE3-
   ETHERNET], the NSP functions of stripping the service-delimiting
   tag, and using a "normalized" Ethernet packet are described.
  
   8.1.  VPLS Encapsulation actions
  
   In a VPLS, a customer Ethernet packet without preamble is
   encapsulated with a header as defined in [PWE3-ETHERNET].  A
   customer Ethernet packet is defined as follows:
  
      - If the packet, as it arrives at the PE, has an encapsulation
        that is used by the local PE as a service delimiter, then that
        encapsulation is stripped before the packet is sent into the
        VPLS.  As the packet exits the VPLS, the packet may have a
        service-delimiting encapsulation inserted.
  
      - If the packet, as it arrives at the PE, has an encapsulation
        that is not service delimiting, then it is a customer packet
        whose encapsulation should not be modified by the VPLS.  This
        covers, for example, a packet that carries customer specific
        VLAN-Ids that the service provider neither knows about nor
        wants to modify.
  
   By following the above rules, the Ethernet packet that traverses a
   VPLS is always a customer Ethernet packet.  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 do not carry across a VPLS a VLAN tag
   that may have only local significance.  The service delimiter may be
   a VC label also, whereby an Ethernet VC given by [PWE3-ETHERNET] can
   serve as the access side connection into a PE.  An RFC1483 PVC
   encapsulation could be another service delimiter.  By limiting the
   scope of locally significant encapsulations to the edge,
  
  
   Lasserre, Kompella et al.                                 [Page 11]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   hierarchical VPLS models can be developed that provide the
   capability to network-engineer VPLS deployments, as described below.
  
   8.1.1.  VPLS Learning actions
  
   Learning is done based on the customer Ethernet packet, as defined
   above.  The Forwarding Information Base (FIB) keeps track of the
   mapping of customer Ethernet packet addressing and the appropriate
   pseudowire to use.  We define two modes of learning: qualified and
   unqualified learning.
  
   In unqualified learning, all the customer VLANs 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 UNI interface where the entire traffic
   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, qualified learning offers the advantage
   of limiting the broadcast scope to a given customer VLAN.
  
  
   9.  Operation of a VPLS
  
   We show here 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.
  
   Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full-
   mesh of tunnels between them for carrying tunneled traffic.  The
   VPLS instance is assigned a VCID (a 32-bit quantity that is unique
   across the provider network across all VPLSs). (Allocation of
   domain-wide unique VCIDs is outside the scope of this draft).
  
   For the above example, say PE1 signals VC Label 102 to PE2 and 103
   to PE3, and PE2 signals VC Label 201 to PE1 and 203 to PE3.
  
   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 multicast the packet to PE2 and
   PE3.  When PE2 receives the packet, it will have an inner label of
   201.  PE2 can conclude that the source MAC address M1 is behind PE1,
  
  
   Lasserre, Kompella et al.                                 [Page 12]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   since it distributed the label 201 to PE1.  It can therefore
   associate MAC address M1 with VC Label 102.
  
                                                         -----
                                                        /  A1 \
           ----                                    ----CE1    |
          /    \          --------       -------  /     |     |
          | A2 CE2-      /        \     /       PE1     \     /
          \    /   \    /          \---/         \       -----
           ----     ---PE2                        |
                       | Service Provider Network |
                        \          /   \         /
                 -----  PE3       /     \       /
                 |Agg|_/  --------       -------
                -|   |
         ----  / -----  ----
        /    \/    \   /    \                 CE = Customer Edge Router
        | A3 CE3    --C4 A4 |                 PE = Provider Edge Router
        \    /         \    /                 Agg = Layer 2 Aggregation
         ----           ----
  
  
  
   9.1.  MAC Address Aging
  
   PEs that learn remote MAC addresses need to have an aging mechanism
   to remove unused entries associated with a VC Label.  This is
   important both for conservation of memory as well as for
   administrative purposes.  For example, if a customer site A is shut
   down, eventually, the other PEs should unlearn A's MAC address.
  
   As packets arrive, MAC addresses are remembered.  The aging timer
   for MAC address M SHOULD be reset when a packet is received with
   source MAC address M.
  
   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) VCs must be setup between the PE
   routers.  While this creates signaling overhead, the real detriment
   to large scale deployment is the packet replication requirements for
   each provisioned VCs 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 device 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 PE VPLS access points.
  
  
   Lasserre, Kompella et al.                                 [Page 13]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
  
   It is often beneficial to extend the VPLS service tunneling
   techniques into the MTU domain.  This can be accomplished by
   treating the MTU device as a PE device and provisioning VCs between
   it and every other edge, as an basic VPLS.  An alternative is to
   utilize [PWE3-ETHERNET] VCs or Q-in-Q VCs between the MTU 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. This section focuses
   on this alternative approach.  The [VPLS] mesh core tier VCs (Hub)
   are augmented with access tier VCs (Spoke) to form a two tier
   hierarchical VPLS (H-VPLS).
  
   Spoke VCs may include any L2 tunneling mechanism, expanding the
   scope of the first tier to include non-bridging VPLS PE routers. The
   non-bridging PE router would extend a Spoke VC from a Layer-2 switch
   that connects to it, through the service core network, to a bridging
   VPLS PE router supporting Hub VCs.  We also describe how VPLS-
   challenged nodes and low-end CEs without MPLS capabilities may
   participate in a hierarchical VPLS.
  
   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 devices for supporting the spoke connections.
  
   For rest of this discussion we will refer to a bridging capable MTU
   device as MTU-s and a non-bridging capable PE device as PE-r.  A
   routing and bridging capable device will be referred to as PE-rs.
  
   10.1.1.  Spoke connectivity for bridging-capable devices
  
   As shown in the figure below, consider the case where an MTU-s
   device has a single connection to the PE-rs device placed in the CO.
   The PE-rs devices are connected in a basic VPLS full mesh.   To
   participate in the VPLS service, MTU-s device creates a single
   point-to-point tunnel LSP to the PE-rs device in the CO.  We will
   call this the spoke connection.  For each VPLS service, a single
   spoke pseudowire is setup between the MTU-s and the PE-rs based on
   [PWE3-CTRL]. Unlike traditional pseudowires that terminate on a
   physical (or a VLAN-tagged logical) port at each end, the spoke VC
   terminates on a virtual bridge instance on the MTU-s and the PE-rs
   devices.
  
  
  
  
  
  
  
  
  
   Lasserre, Kompella et al.                                 [Page 14]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
                                                          PE2-rs
                                                          ------
                                                         /      \
                                                        |   --   |
                                                        |  /  \  |
    CE-1                                                |  \B /  |
     \                                                   \  --  /
      \                                                  /------
       \   MTU-s                          PE1-rs        /   |
        \ ------                          ------       /    |
         /      \                        /      \     /     |
        | \ --   |      VC-1            |   --   |---/      |
        |  /  \--|- - - - - - - - - - - |--/  \  |          |
        |  \B /  |                      |  \B /  |          |
         \ /--  /                        \  --  / ---\      |
          /-----                          ------      \     |
         /                                             \    |
       ----                                             \ ------
      |Agg |                                             /      \
       ----                                             |  --    |
      /    \                                            | /  \   |
     CE-2  CE-3                                         | \B /   |
                                                         \ --   /
    MTU-s = Bridging capable MTU                          ------
    PE-rs = VPLS capable PE                               PE3-rs
  
    --
   /  \
   \B / = Virtual VPLS(Bridge)Instance
    --
    Agg = Layer-2 Aggregation
  
   The MTU-s device and the PE-rs device treat each spoke connection
   like an access port of the VPLS service. On access ports, the
   combination of the physical port and/or the VLAN tag is used to
   associate the traffic to a VPLS instance while the pseudowire tag
   (e.g., VC label) is used to associate the traffic from the virtual
   spoke port with a VPLS instance, followed by a standard L2 lookup to
   identify which customer port the frame needs to be sent to.
  
   The signaling and association of the spoke connection to the VPLS
   service may be done by introducing extensions to the LDP signaling
   as specified in [PWE3-CTRL].
  
   10.1.1.1.  MTU-s Operation
  
   MTU-s device 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 virtual spoke port.
   Packets to unknown destination are replicated to all ports in the
   service including the virtual spoke port.  Once the MAC address is
  
  
   Lasserre, Kompella et al.                                 [Page 15]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   learned, traffic between CE1 and CE2 will be switched locally by the
   MTU-s device saving the link capacity of the connection to the PE-
   rs.  Similarly traffic between CE1 or CE2 and any remote destination
   is switched directly on to the spoke connection and sent to the PE-
   rs over the point-to-point pseudowire.
  
   Since the MTU-s is bridging capable, only a single pseudowire 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 connection
   pseudowire. However, to maintain a uniform end-to-end control plane
   based on MPLS signaling, [PWE3-CTRL] can be used for distribution of
   pseudowire tags (e.g., Q-in-Q tags or VC labels) between MTU-s and
   PE-rs
  
   10.1.1.2.  PE-rs Operation
  
   The PE-rs device 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 in
   [VPLS].   The operation on the PE-rs node is identical to that
   described in [VPLS] with one addition.  A point-to-point VC
   associated with the VPLS is regarded as a virtual port (see
   discussion in Section 5.6.1 on service delimiting).  The operation
   on the virtual spoke port is identical to the operation on an access
   port as described in the earlier section.  As shown in the figure
   above, each PE-rs device switches traffic between aggregated access
   VCs that look like virtual ports and the network side VPLS VCs.
  
   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
     VCs per service between all devices participating in the VPLS
     service.
  - Minimizes signaling overhead since fewer VC-LSPs are required for
     the VPLS service.
  - 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 device and all of it’s
     locally connected MTU-s and PE-r.
  - Addition of other sites requires configuration of the new MTU-s
     device but does not require any provisioning of the existing MTU-s
     devices on that service.
  
  
   Lasserre, Kompella et al.                                 [Page 16]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
  - Hierarchical connections can be used to create VPLS service that
     spans multiple service provider domains. This is explained in a
     later section.
  
   10.1.3.  Spoke connectivity for non-bridging devices
  
   In some cases, a bridging PE-rs device may not be deployed in a CO
   or a multi-tenant building while a PE-r might already be deployed.
   If there is a need to provide VPLS service from the CO where the PE-
   rs device is not available, the service provider may prefer to use
   the PE-r device in the interim.  In this section, we explain how a
   PE-r device that does not support any of the VPLS bridging
   functionality can participate in the VPLS service.
  
   As shown in this figure, the PE-r device creates a point-to-point
   tunnel LSP to a PE-rs device.  Then for every access port that needs
  
                                                          PE2-rs
                                                          ------
                                                         /      \
                                                        |   --   |
                                                        |  /  \  |
    CE-1                                                |  \B /  |
     \                                                   \  --  /
      \                                                  /------
       \   PE-r                           PE1-rs        /   |
        \ ------                          ------       /    |
         /      \                        /      \     /     |
        | \      |      VC-1            |   --   |---/      |
        |  ------|- - - - - - - - - - - |--/  \  |          |
        |   -----|- - - - - - - - - - - |--\B /  |          |
         \ /    /                        \  --  / ---\      |
          ------                          ------      \     |
         /                                             \    |
       ----                                             \------
      | Agg|                                            /      \
       ----                                            |  --    |
      /    \                                           | /  \   |
     CE-2  CE-3                                        | \B /   |
                                                        \ --   /
                                                         ------
                                                         PE3-rs
  
  
   to participate in a VPLS service, the PE-r device creates a point-
   to-point [PWE3-ETHERNET] VC that terminates on the physical port at
   the PE-r and terminates on the virtual bridge instance of the VPLS
   service at the PE-rs.
  
  
   10.1.3.1.  PE-r Operation
  
  
   Lasserre, Kompella et al.                                 [Page 17]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
  
   The PE-r device is defined as a device that supports routing but
   does not support any bridging functions.  However, it is capable of
   setting up [PWE3-ETHERNET] VCs between itself and the PE-rs.  For
   every port that is supported in the VPLS service, a [PWE3-ETHERNET]
   VC is setup from the PE-r to the PE-rs.  Once the VCs are setup,
   there is no learning or replication function required on part of the
   PE-r.  All traffic received on any of the access ports is
   transmitted on the VC.  Similarly all traffic received on a VC is
   transmitted to the access port where the VC terminates.  Thus
   traffic from CE1 destined for CE2 is switched at PE-rs and not at
   PE-r.
  
   This approach adds more overhead than the bridging capable (MTU-s)
   spoke approach since a VC is required for every access port that
   participates in the service versus a single VC required per service
   (regardless of access ports) when a MTU-s type device 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 device.
  
  
   10.1.3.2.  PE-rs Operation
  
   The operation of PE-rs is independent of the type of device at the
   other end of the spoke connection.  Whether there is a bridging
   capable device (MTU-s) at the other end of the spoke connection or
   there is a non-bridging device (PE-r) at the other end of the spoke
   connection, the operation of PE-rs is exactly the same.  Thus, the
   spoke connection from the PE-r is treated as a virtual port and the
   PE-rs device switches traffic between the virtual port, access ports
   and the network side VPLS VCs once it has learned the MAC addresses.
  
  
   10.2.  Redundant Spoke Connections
  
   An obvious weakness of the hub and spoke approach described thus far
   is that the MTU device has a single connection to the PE-rs device.
   In case of failure of the connection or the PE-rs device, the MTU
   device 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 device.
   The mechanism described is identical for both, MTU-s and PE-r type
   of devices
  
  
   10.2.1.  Dual-homed MTU device
  
   To protect from connection failure of the VC or the failure of the
   PE-rs device, the MTU-s device or the PE-r is dual-homed into two
  
  
   Lasserre, Kompella et al.                                 [Page 18]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   PE-rs devices, as shown in figure-3.  The PE-rs devices must be part
   of the same VPLS service instance.
  
   An MTU-s device will setup two [PWE3-ETHERNET] VCs (one each to PE-
   rs1 and PE-rs2) for each VPLS instance. One of the two VC is
   designated as primary and is the one that is actively used under
   normal conditions, while the second VC is designated as secondary
   and is held in a standby state.  The MTU device negotiates the VC-
   labels for both the primary and secondary VC, but does not use the
   secondary VC unless the primary VC fails.  Since only one link is
   active at a given time, a loop does not exist and hence 802.1D
   spanning tree is not required.
  
                                                          PE2-rs
                                                          ------
                                                         /      \
                                                        |   --   |
                                                        |  /  \  |
    CE-1                                                |  \B /  |
      \                                                  \  --  /
       \                                                 /------
        \  MTU-s                          PE1-rs        /   |
         \------                          ------       /    |
         /      \                        /      \     /     |
        |   --   |   Primary VC         |   --   |---/      |
        |  /  \--|- - - - - - - - - - - |--/  \  |          |
        |  \B /  |                      |  \B /  |          |
         \  -- \/                        \  --  / ---\      |
          ------\                         ------      \     |
          /      \                                     \    |
         /        \                                     \ ------
        /          \                                     /      \
       CE-2         \                                   |  --    |
                     \     Secondary VC                 | /  \   |
                      - - - - - - - - - - - - - - - - - |-\B /   |
                                                         \ --   /
                                                          ------
                                                          PE3-rs
  
  
   10.2.2.  Failure detection and recovery
  
   The MTU-s device controls the usage of the VC links to the PE-rs
   nodes.  Since LDP signaling is used to negotiate the VC-labels, the
   hello messages used for the LDP session can be used to detect
   failure of the primary VC.
  
   Upon failure of the primary VC, MTU-s device immediately switches to
   the secondary VC.  At this point the PE3-rs device that terminates
   the secondary VC starts learning MAC addresses on the spoke VC.  All
   other PE-rs nodes in the network think that CE-1 and CE-2 are behind
  
  
   Lasserre, Kompella et al.                                 [Page 19]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   PE1-rs and may continue to send traffic to PE1-rs until they learn
   that the devices are now behind PE3-rs.  The relearning 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 device where the secondary VC got activated may send out a
   flush message, using the MAC TLV as defined in Section 6, to all
   other PE-rs devices participating in the VPLS service.  Upon
   receiving the message, all PE-rs 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 gateway devices.  A
   single VC is setup per VPLS service to connect the two domains
   together.  The VPLS gateway device joins two VPLS services together
   to form a single multi-domain VPLS service. .  The requirements and
   functionality required from a VPLS gateway device will be explained
   in a future version of this document.
  
   11.  Hierarchical VPLS model using Ethernet Access Network
  
   In the previous section, a two-tier hierarchical model that consists
   of hub-and-spoke topology between MTU-s devices and PE-rs devices and
   a full-mesh topology among PE-rs devices was discussed. In this
   section the two-tier hierarchical model is expanded to include an
   Ethernet access network. This model retains the hierarchical
   architecture discussed previously in that it includes MTU-s devices
   and PE-rs devices and also utilized a full-mesh topology among PE-rs
   devices. 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 can categorize Ethernet access networks into the following three
   groups:
  
     1. Based on existing 802.1q standard (this is comparable to the
        situation where the customer comes ino on a VLAN-tagged port)
     2. Based on an extension to the IEEE 802.1q standard that tunnels
        802.1q VLANs using a service provider 802.1q tag (referred to as
        Q-in-Q)
     3. Based on Q-in-Q tunneling with ability to distribute .1q tags
        using MPLS control plane
  
  
  
  
  
   Lasserre, Kompella et al.                                 [Page 20]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   For the first category, the MTU-s and all the other nodes in the
   access network (excluding PE-rs devices) have standard 802.1q
   Ethernet switch capability. However, the PE-rs device is a VPLS-
   capable router as described previously.
  
   For the second category, in addition to the functionality described
   in the category above, the MTU-s and the PE-rs are required to
   support Q-in-Q tunneling capabilities and the Ethernet nodes in
   between are required to handle larger data frames (to accommodate the
   additional encapsulation).
  
   The third category requires the MTU-s and the PE-rs to support LDP
   signaling for the distribution of Q-in-Q tags (i.e., MTU-s and PE-rs
   to have MPLS signaling capability, without MPLS encapsulation) in
   addition to the functionality described in categories 1 and 2
   described above.
  
   It should be noted that since the Ethernet access network can have
   any arbitrary topology, standard 802.1D Spanning Tree Protocol (STP)
   may be required for loop detection and prevention. However, the use
   of spanning tree is topology dependent and may or may not be
   required.
  
   The connectivity within the service provider core is unchanged. Thus,
   a PE-rs may need to run STP on its Ethernet access interfaces and
   split-horizon on its MPLS/IP network interfaces. In a topology where
   MTU-s devices are directly connected to PE-rs devices, STP is not
   required on the access network.
  
   The following figure shows a VPLS network and several possible ways
   of connecting customer CE devices to the network. As it can be seen
   CEs can be either connected directly to PE-rs (or PE-r) or they can
   be first aggregated by an MTU-s and then connected to PE-rs or they
   can be connected via an Ethernet Access network to the PE-rs.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
   Lasserre, Kompella et al.                                 [Page 21]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
       +----+                                         +------+    +----+
       +CE1 +--+                                  +---|MTU-s |----|CE2 |
       +----+  |    ........................      |   +------+    +----+
       VPLS A  |  +------+               +------+ |      |        VPLS A
               +--| PE-rs|-- Service ----|PE-rs |-+      |       +----+
                  +------+   Provider    +------+        +-------|CE2’|
                  / .        Backbone    . \                     +----+
                 /  .          |           .  \      +-----+      VPLS B
       +----+   /   .          |           .   \    / Ether \
       +CE1’+--+    .          |           .    +--| Access  |
       +----+       .        +-----+       .       | Network |
       VPLS B       .........|PE-rs|........        \       /
                             +-----+                 +-----+
                               |                        |
                               |                        |
                             +----+                  +------+   +----+
                             |CE3 |                  |MTU-s |---|CE3’|
                             +----+                  +------+   +----+
                             VPLS A                     |        VPLS B
                                                        |
                                                        |      +----+
                                                        +------|CE4’|
                                                               +----+
                                                             VPLS B
  
  
   11.1.  Port-based v.s. VLAN-based VPLS operation
  
   Where a customer uses a port-based VPLS service, all customer
   traffic received from that port, regardless of whether it has vlan
   tags or not, is directed to a single VPLS instance. In the MTU-s,
   this is done by assigning a service provider VLAN (SP-VLAN) tag to
   that customer port. If the customer traffic is already tagged, the
   SP-VLAN serves as the outer tag. The SP-VLAN tag serves as a VPLS
   identifier which identifies a FIB associated with that particular
   VPLS. MAC address learning is done using unqualified learning.  The
   customer packets are then forwarded through the FIB to the
   appropriate pseudowire based on the destination MAC address. In the
   reverse direction, the pseudowire tag identifies the VPLS instance
   and thus the FIB.  The packet is forwarded to the proper Ethernet
   port based on the destination MAC address. When the packet leaves
   the PE-rs toward the MTU-s, it will be appended with the SP-VLAN tag
   associated with that VPLS.
  
   Where a customer uses a VLAN-based VPLS service, if the traffic
   within each customer VLAN is to be isolated from each other and each
   one has its own broadcast domain, then each customer VLAN is mapped
   to a single VPLS instance. If the Service Provider assigns the
   customer VLAN tags, then the Service provider can ensure the
   uniqueness of these VLAN tags among different customers and a given
   customer VLAN tag can be used as a VPLS identifier. However, if
  
  
   Lasserre, Kompella et al.                                 [Page 22]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   customers assigns their own VLAN tags independently, then the MTU-s
   MUST map each customer VLAN into a unique SP-VLAN. Subsequently, the
   SP-VLAN will be used as a VPLS identifier to index the proper FIB
   and to forward traffic based on destination MAC address. The
   operation of PE-rs in this case remains same as before.
  
   The following shows the Q-in-Q tunneling encapsulation which is
   applied when Ethernet data plane is used between MTU-s and PE-rs.
  
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   MAC Dest. Address                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       MAC DA cont.            |   MAC Source Address          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        MAC SA cont.                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Ether Type = 0x8100       |      SP-VLAN          |SP .1p |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Ether Type = 0x8100       |      CE-VLAN          |CE .1p |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Ether Type / Length      |          Payload              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Payload                             |
      |                              "                                |
      |                              "                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
   12.  Significant Modifications
  
   Between rev 01 and this one, the WG mailing comments and merging
   with draft-sajassi-vpls-architectures-00.txt led to the following
   changes:
       o update MAC TLV section to conform to 802.1d bridging
       o add Q-in-Q section
       o remove qualified learning
       o align with L2 framework terminology
       o clean up descriptions, typos
       o updated references
  
   13.  Acknowledgments
  
   We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel
   Halpern, Rick Wilder,Jim Guichard, Steve Phillips, Norm Finn, Matt
   Squire, Muneyoshi Suzuki, Waldemar Augustyn, and Eric Rosen for
   their valuable feedback.
  
  
  
  
  
  
   Lasserre, Kompella et al.                                 [Page 23]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   14.  Security Considerations
  
   Security issues resulting from this draft will be discussed in
   greater depth at a later point.  It is recommended in [RFC3036] that
   LDP security (authentication) methods be applied.  This would
   prevent unauthorized participation by a PE in a VPLS.  Traffic
   separation for a VPLS is effected by using VC labels.  However, for
   additional levels of security, the customer MAY deploy end-to-end
   security, which is out of the scope of this draft.
  
   15.  Intellectual Property Considerations
  
   This document is being submitted for use in IETF standards
   discussions.
  
   16.  Full Copyright Statement
  
      Copyright (C) The Internet Society (2001).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
  
   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
  
   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
  
   17.  References
  
   [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet
   Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-
   01.txt, Work in progress, November 2002.
  
   [PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", draft-ietf-
   pwe3-control-protocol-01.txt, Work in progress, November 2002.
  
  
  
   Lasserre, Kompella et al.                                 [Page 24]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   [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.
  
   [BGP-VPN] Rosen and Rekhter, "BGP/MPLS VPNs". RFC 2547, March 1999.
  
   [VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)",
   draft-ietf-ppvpn-vpls-requirements-01.txt, Work in progress, October
   2002.
  
   [RFC3036] "LDP Specification", L. Andersson, et al.  RFC 3036.
   January 2001.
  
   [DNS-DISC] "Using DNS for VPN Discovery", J. Luciani et al, draft-
   luciani-ppvpn-vpn-discovery-03.txt, Work in Progress, October 2002.
  
   [BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network-
   based VPNs", Ould-Brahim, et. al., draft-ietf-ppvpn-bgpvpn-auto-
   03.txt, Work in Progress, August 2002.
  
   [LDP-DISC] "Discovering Nodes and Services in a VPLS Network", O.
   Stokes et al, draft-stokes-ppvpn-vpls-discover-00.txt, Work in
   Progress, June 2002.
  
   [VPLS-BRIDGING] "Bridging and VPLS", draft-finn-ppvpn-bridging-vpls-
   00.txt, Work in Progress, June 2002.
  
   18.  Authors' Addresses
  
   Marc Lasserre
   Riverstone Networks
   5200 Great America Pkwy
   Santa Clara, CA 95054
   Email: marc@riverstonenet.com
  
   Vach Kompella
   TiMetra Networks
   274 Ferguson Dr.
   Mountain View, CA 94043
   Email: vkompella@timetra.com
  
  
  
   Lasserre, Kompella et al.                                 [Page 25]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   Sunil Khandekar
   TiMetra Networks
   274 Ferguson Dr.
   Mountain View, CA 94043
   Email: sunil@timetra.com
  
   Nick Tingle
   TiMetra Networks
   274 Ferguson Dr.
   Mountain View, CA 94043
   Email: nick@timetra.com
  
   Ali Sajassi
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   Email: sajassi@cisco.com
  
   Loa Andersson
   Utfors Bredband AB
   Rasundavagen 12 169 29 Solna
   Email: loa.andersson@utfors.se
  
   Pascal Menezes
   Email: pascalm1@yahoo.com
   Andrew Smith
   Consultant
   Email: ah_smith@pacbell.net
  
   Giles Heron
   PacketExchange Ltd.
   The Truman Brewery
   91 Brick Lane
   LONDON E1 6QL
   United Kingdom
   Email: giles@packetexchange.net
  
   Juha Heinanen
   Song Networks, Inc.
   Email: jh@lohi.eng.song.fi
  
   Tom S. C. Soon
   SBC Technology Resources Inc.
   4698 Willow Road
   Pleasanton, CA 94588
   Email: sxsoon@tri.sbc.com
  
   Yetik Serbest
   SBC Communications
   9505 Arboretum Blvd.
   Austin TX 78759
  
  
   Lasserre, Kompella et al.                                 [Page 26]


   Internet Draft draft-lasserre-vkompella-ppvpn-vpls-03.txt  Jan 2003
  
  
   serbest@tri.sbc.com
  
   Eric Puetz
   SBC Communications
   9505 Arboretum Blvd.
   Austin TX 78759
   puetz@tri.sbc.com
  
   Ron Haberman
   Masergy Inc.
   2901 Telestar Ct.
   Falls Church, VA 22042
   Email: ronh@masergy.com
  
   Luca Martini
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO, 80021
   Email: luca@level3.net
  
   Rob Nath
   Riverstone Networks
   5200 Great America Pkwy
   Santa Clara, CA 95054
   Email: rnath@riverstonenet.com
  
   Vasile Radaoca
   Nortel Networks
   600 Technology Park
   Billerica MA 01821
   Email: vasile@nortelnetworks.com
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
   Lasserre, Kompella et al.                                 [Page 27]
  

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/