draft-ietf-l2vpn-vpls-bgp-03.txt   draft-ietf-l2vpn-vpls-bgp-04.txt 
Network Working Group K. Kompella (Editor) Network Working Group K. Kompella, Ed.
Internet Draft Y. Rekhter (Editor) Internet-Draft Y. Rekhter, Ed.
Category: Standards Track Juniper Networks Expires: August 23, 2005 Juniper Networks
Expires: July 2005 January 2005 February 19, 2005
draft-ietf-l2vpn-vpls-bgp-03.txt
Virtual Private LAN Service Virtual Private LAN Service
draft-ietf-l2vpn-vpls-bgp-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of Section 3 of RFC 3667. By submitting this Internet-Draft, each
or will be disclosed, and any of which I become aware will be author represents that any applicable patent or other IPR claims of
disclosed, in accordance with RFC 3668. which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
This document is an Internet-Draft and is in full conformance with RFC 3668.
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
Virtual Private LAN Service (VPLS), also known as Transparent LAN Virtual Private LAN Service (VPLS), also known as Transparent LAN
Service, and Virtual Private Switched Network service, is a useful Service, and Virtual Private Switched Network service, is a useful
Service Provider offering. The service offered is a Layer 2 Virtual Service Provider offering. The service offers a Layer 2 Virtual
Private Network (VPN); however, in the case of VPLS, the customers in Private Network (VPN); however, in the case of VPLS, the customers in
the VPN are connected by a multipoint network, in contrast to the the VPN are connected by a multipoint network, in contrast to the
usual Layer 2 VPNs, which are point-to-point in nature. usual Layer 2 VPNs, which are point-to-point in nature.
This document describes the functions required to offer VPLS, and This document describes the functions required to offer VPLS, a
describes a mechanism for signaling a VPLS, as well as for forwarding mechanism for signaling a VPLS, and rules for forwarding VPLS frames
VPLS frames across a packet switched network. across a packet switched network.
Conventions used in this document Table of Contents
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1.1 Scope of this Document . . . . . . . . . . . . . . . . . . 3
document are to be interpreted as described in RFC 2119 [1]. 1.2 Conventions used in this document . . . . . . . . . . . . 4
1.3 Changes from last version . . . . . . . . . . . . . . . . 4
2. Functional Model . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Interactions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Autodiscovery . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1 Functions . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2 Protocol Specification . . . . . . . . . . . . . . . . 9
3.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Setup and Teardown . . . . . . . . . . . . . . . . . . 9
3.2.2 Signaling PE Capabilities . . . . . . . . . . . . . . 11
3.3 Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 a) VPLS-to-VPLS connections at the AS border
routers. . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 b) EBGP redistribution of VPLS information between
ASBRs. . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3 c) Multi-hop EBGP redistribution of VPLS
information between ASes. . . . . . . . . . . . . . . 14
3.4 Multi-homing and Path Selection . . . . . . . . . . . . . 15
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1 MAC address learning . . . . . . . . . . . . . . . . . 17
4.2.2 Flooding . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3 "Split Horizon" Forwarding . . . . . . . . . . . . . . 18
5. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1 Normative References . . . . . . . . . . . . . . . . . . . 22
8.2 Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 26
1. Introduction 1. Introduction
Virtual Private LAN Service (VPLS), also known as Transparent LAN Virtual Private LAN Service (VPLS), also known as Transparent LAN
Service, and Virtual Private Switched Network service, is a useful Service, and Virtual Private Switched Network service, is a useful
service offering. A Virtual Private LAN appears in (almost) all service offering. A Virtual Private LAN appears in (almost) all
respects as a LAN to customers of a Service Provider. However, in a respects as a LAN to customers of a Service Provider. However, in a
VPLS, the customers are not all connected to a single LAN; the VPLS, the customers are not all connected to a single LAN; the
customers may be spread across a metro or wide area. In essence, a customers may be spread across a metro or wide area. In essence, a
VPLS glues several individual LANs across a packet-switched network VPLS glues several individual LANs across a packet-switched network
to appear and function as a single LAN [2]. to appear and function as a single LAN ([6]).
This document describes the functions needed to offer VPLS, and goes This document describes the functions needed to offer VPLS, and goes
on to describe a mechanism for signaling a VPLS, as well as a on to describe a mechanism for signaling a VPLS, as well as a
mechanism for transport of VPLS frames over tunnels across a packet mechanism for transport of VPLS frames over tunnels across a packet
switched network. The signaling mechanism uses BGP as the control switched network. The signaling mechanism uses BGP as the control
plane protocol. This document also briefly discusses deployment plane protocol. This document also briefly discusses deployment
options, in particular, the notion of decoupling functions across options, in particular, the notion of decoupling functions across
devices. devices.
Alternative approaches include: [3], which allows one to build a Alternative approaches include: [11], which allows one to build a
Layer 2 VPN with Ethernet as the interconnect; and [4], which allows Layer 2 VPN with Ethernet as the interconnect; and [10]), which
one to set up an Ethernet connection across a packet-switched allows one to set up an Ethernet connection across a packet-switched
network. Both of these, however, offer point-to-point Ethernet network. Both of these, however, offer point-to-point Ethernet
services. What distinguishes VPLS from the above two is that a VPLS services. What distinguishes VPLS from the above two is that a VPLS
offers a multipoint service. A mechanism for setting up pseudowires offers a multipoint service. A mechanism for setting up pseudowires
for VPLS using the Label Distribution Protocol (LDP) is defined in for VPLS using the Label Distribution Protocol (LDP) is defined in
[5]. [7].
1.1. Scope of this Document 1.1 Scope of this Document
This document has four major parts: defining a VPLS functional model; This document has four major parts: defining a VPLS functional model;
defining a control plane for setting up VPLS; defining the data plane defining a control plane for setting up VPLS; defining the data plane
for VPLS (encapsulation and forwarding of data); and defining various for VPLS (encapsulation and forwarding of data); and defining various
deployment options. deployment options.
The functional model underlying VPLS is laid out in section 2. This The functional model underlying VPLS is laid out in Section 2. This
describes the service being offered, the network components that describes the service being offered, the network components that
interact to provide the service, and at a high level their interact to provide the service, and at a high level their
interactions. interactions.
The control plane described in this document uses Multiprotocol BGP The control plane described in this document uses Multiprotocol BGP
[6] to establish VPLS service, i.e., for the autodiscovery of VPLS [3] to establish VPLS service, i.e., for the autodiscovery of VPLS
members and for the setup and teardown of the pseudowires that members and for the setup and teardown of the pseudowires that
constitute a given VPLS. Section 3 also describes how a VPLS that constitute a given VPLS instance. Section 3 focuses on this, and
spans Autonomous System boundaries is set up, as well as how also describes how a VPLS that spans Autonomous System boundaries is
multi-homing is handled. Using BGP as the control plane for VPNs is set up, as well as how multi-homing is handled. Using BGP as the
not new (see [3], [7] and [8]): what is described here is based on control plane for VPNs is not new (see [11], [9] and [8]): what is
the mechanisms proposed in [7]. described here is based on the mechanisms proposed in [9].
The forwarding plane and the actions that a participating PE must The forwarding plane and the actions that a participating PE must
take is described in section 4. take is described in Section 4.
In section 5, the notion of 'decoupled' operation is defined, and the In Section 5, the notion of 'decoupled' operation is defined, and the
interaction of decoupled and non-decoupled PEs is described. interaction of decoupled and non-decoupled PEs is described.
Decoupling allows for more flexible deployment of VPLS. Decoupling allows for more flexible deployment of VPLS.
1.2 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 ([1]).
1.3 Changes from last version
[NOTE to RFC Editor: this section is to be removed before
publication.]
Incorporated IDR review comments from Eric Ji, Chaitanya Kodeboyina,
and Mike Loomis. Most changes are clarifications and rewording for
better readability. The substantive changes are to remove several
flags from the control field.
2. Functional Model 2. Functional Model
This will be described with reference to Figure 1. This will be described with reference to the following figure.
Figure 1: Example of a VPLS
----- -----
/ A1 \ / A1 \
---- ____CE1 | ---- ____CE1 |
/ \ -------- -------- / | | / \ -------- -------- / | |
| A2 CE2- / \ / PE1 \ / | A2 CE2- / \ / PE1 \ /
\ / \ / \___/ | \ ----- \ / \ / \___/ | \ -----
---- ---PE2 | \ ---- ---PE2 | \
| | \ ----- | | \ -----
| Service Provider Network | \ / \ | Service Provider Network | \ / \
| | CE5 A5 | | | CE5 A5 |
| ___ | / \ / | ___ | / \ /
|----| \ / \ PE4_/ ----- |----| \ / \ PE4_/ -----
|u-PE|--PE3 / \ / |u-PE|--PE3 / \ /
|----| -------- ------- |----| -------- -------
---- / | ---- ---- / | ----
/ \/ \ / \ CE = Customer Edge Device / \/ \ / \ CE = Customer Edge Device
| A3 CE3 --CE4 A4 | PE = Provider Edge Router | A3 CE3 --CE4 A4 | PE = Provider Edge Router
\ / \ / u-PE = Layer 2 Aggregation \ / \ / u-PE = Layer 2 Aggregation
---- ---- A<n> = Customer site n ---- ---- A<n> = Customer site n
2.1. Terminology Figure 1: Example of a VPLS
Terminology similar to that in [7] is used, with the addition of "u- 2.1 Terminology
PE", a Layer 2 PE device used for Layer 2 aggregation. A u-PE is
owned and operated by the Service Provider (as is the PE). PE and u- Terminology similar to that in [9] is used, with the addition of
PE devices are "VPLS-aware", which means that they know that a VPLS "u-PE", a Layer 2 PE device used for Layer 2 aggregation. The notion
service is being offered. We will call these VPLS edge devices, of u-PE is described further in Section 5. PE and u-PE devices are
which could be either a PE or an u-PE, a VE. "VPLS-aware", which means that they know that a VPLS service is being
offered. We will call these VPLS edge devices, which could be either
a PE or an u-PE, a VE.
In contrast, the CE device (which may be owned and operated by either In contrast, the CE device (which may be owned and operated by either
the SP or the customer) is VPLS-unaware; as far as the CE is the SP or the customer) is VPLS-unaware; as far as the CE is
concerned, it is connected to the other CEs in the VPLS via a Layer 2 concerned, it is connected to the other CEs in the VPLS via a Layer 2
switched network. This means that there should be no changes to a CE switched network. This means that there should be no changes to a CE
device, either to the hardware or the software, in order to offer device, either to the hardware or the software, in order to offer
VPLS. VPLS.
A CE device may be connected to a PE or a u-PE via Layer 2 switches A CE device may be connected to a PE or a u-PE via Layer 2 switches
that are VPLS-unaware. From a VPLS point of view, such Layer 2 that are VPLS-unaware. From a VPLS point of view, such Layer 2
skipping to change at page 4, line 41 skipping to change at page 6, line 14
The term "demultiplexor" refers to an identifier in a data packet The term "demultiplexor" refers to an identifier in a data packet
that identifies both the VPLS to which the packet belongs as well as that identifies both the VPLS to which the packet belongs as well as
the ingress PE. In this document, the demultiplexor is an MPLS the ingress PE. In this document, the demultiplexor is an MPLS
label. label.
The term "VPLS" will refer to the service as well as a particular The term "VPLS" will refer to the service as well as a particular
instantiation of the service (i.e., an emulated LAN); it should be instantiation of the service (i.e., an emulated LAN); it should be
clear from the context which usage is intended. clear from the context which usage is intended.
2.2. Assumptions 2.2 Assumptions
The Service Provider Network is a packet switched network. The PEs The Service Provider Network is a packet switched network. The PEs
are assumed to be (logically) full-meshed with tunnels over which are assumed to be (logically) full-meshed with tunnels over which
packets that belong to a service (such as VPLS) are encapsulated and packets that belong to a service (such as VPLS) are encapsulated and
forwarded. These tunnels can be IP tunnels, such as GRE, or MPLS forwarded. These tunnels can be IP tunnels, such as GRE, or MPLS
tunnels, established by RSVP-TE or LDP. These tunnels are tunnels, established by RSVP-TE or LDP. These tunnels are
established independently of the services offered over them; the established independently of the services offered over them; the
signaling and establishment of these tunnels are not discussed in signaling and establishment of these tunnels are not discussed in
this document. this document.
"Flooding" and MAC address "learning" (see section 4) are an integral "Flooding" and MAC address "learning" (see Section 4) are an integral
part of VPLS. However, these activities are private to an SP device, part of VPLS. However, these activities are private to an SP device,
i.e., in the VPLS described below, no SP device requests another SP i.e., in the VPLS described below, no SP device requests another SP
device to flood packets or learn MAC addresses on its behalf. device to flood packets or learn MAC addresses on its behalf.
All the PEs participating in a VPLS are assumed to be fully meshed, All the PEs participating in a VPLS are assumed to be fully meshed,
i.e., every (ingress) PE can send a VPLS packet to the egress PE(s) i.e., every (ingress) PE can send a VPLS packet to the egress PE(s)
directly, without the need for an intermediate PE (see the section directly, without the need for an intermediate PE (see
below on "Split Horizon" Flooding). This assumption reduces (but Section 4.2.3.)
does not eliminate) the need to run Spanning Tree Protocol among the
PEs.
2.3. Interactions 2.3 Interactions
VPLS is a successful "LAN Service" if CE devices that belong to VPLS VPLS is a "LAN Service" in that CE devices that belong to VPLS V can
V can interact through the SP network as if they were connected by a interact through the SP network as if they were connected by a LAN.
LAN. VPLS is "private" if CE devices that belong to different VPLSs VPLS is "private" in that CE devices that belong to different VPLSs
cannot interact. VPLS is "virtual" if multiple VPLSs can be offered cannot interact. VPLS is "virtual" in that multiple VPLSs can be
over a common packet switched network. offered over a common packet switched network.
PE devices interact to "discover" all the other PEs participating in PE devices interact to "discover" all the other PEs participating in
the same VPLS (i.e., that are attached to CE devices that belong to the same VPLS, and to exchange demultiplexors. These interactions
the same VPLS), and to exchange demultiplexors. These interactions
are control-driven, not data-driven. are control-driven, not data-driven.
U-PEs interact with PEs to establish connections with remote PEs or u-PEs interact with PEs to establish connections with remote PEs or
u-PEs in the same VPLS. Again, this interaction is control-driven. u-PEs in the same VPLS. This interaction is control-driven.
PE devices can participate simultaneously in both VPLS and IP VPNs
([9]). These are independent services, and the information exchanged
for each type of service is kept separate as the Network Layer
Reachability Information (NLRI) used for this exchange have different
Address Family Identifiers (AFI) and Subsequent Address Family
Identifiers (SAFI). Consequently, an implementation MUST maintain a
separate routing storage for each service. However, multiple
services can use the same underlying tunnels; the VPLS or VPN label
is used to demultiplex the packets belonging to different services.
3. Control Plane 3. Control Plane
There are two primary functions of the VPLS control plane: There are two primary functions of the VPLS control plane:
autodiscovery, and setup and teardown of the pseudowires that autodiscovery, and setup and teardown of the pseudowires that
constitute the VPLS, often called signaling. The first two constitute the VPLS, often called signaling. The first two
subsections describe these functions. The next subsection describes subsections describe these functions. The third subsection describes
the setting up of pseudowires that span Autonomous Systems. The last the setting up of pseudowires that span Autonomous Systems. The last
subsection details how multi-homing is handled. subsection details how multi-homing is handled.
3.1. Autodiscovery 3.1 Autodiscovery
Discovery refers to the process of finding all the PEs that Discovery refers to the process of finding all the PEs that
participate in a given VPLS. A PE can either be configured with the participate in a given VPLS. A PE can either be configured with the
identities of all the other PEs in a given VPLS, or the PE can use identities of all the other PEs in a given VPLS, or the PE can use
some protocol to discover the other PEs. The latter is called some protocol to discover the other PEs. The latter is called
autodiscovery. autodiscovery.
The former approach is fairly configuration-intensive, especially The former approach is fairly configuration-intensive, especially
since it is required (in this and other VPLS approaches) that the PEs since it is required that the PEs participating in a given VPLS are
participating in a given VPLS are fully meshed (i.e., every pair of fully meshed (i.e., that every PE in a given VPLS establish
PEs in a given VPLS establish pseudowires to each other). pseudowires to every other PE in that VPLS). Furthermore, when the
Furthermore, when the topology of a VPLS changes (i.e., a PE is added topology of a VPLS changes (i.e., a PE is added to, or removed from
to, or removed from the VPLS), the VPLS configuration on all PEs in the VPLS), the VPLS configuration on all PEs in that VPLS must be
that VPLS must be changed. changed.
In the autodiscovery approach, each PE "discovers" which other PEs In the autodiscovery approach, each PE "discovers" which other PEs
are part of a given VPLS by means of some protocol, in this case BGP. are part of a given VPLS by means of some protocol, in this case BGP.
This allows each PE's configuration to consist only of the identity This allows each PE's configuration to consist only of the identity
of the VPLS that each customer belongs to, not the identity of every of the VPLS instance established on this PE, not the identity of
other PE in that VPLS. Moreover, when the topology of a VPLS every other PE in that VPLS instance -- that is auto-discovered.
changes, only the affected PE's configuration changes; other PEs Moreover, when the topology of a VPLS changes, only the affected PE's
automatically find out about the change and adapt. configuration changes; other PEs automatically find out about the
change and adapt.
3.1.1. Functions 3.1.1 Functions
A PE that participates in a given VPLS V must be able to tell all A PE that participates in a given VPLS V must be able to tell all
other PEs in VPLS V that it is also a member of V. A PE must also other PEs in VPLS V that it is also a member of V. A PE must also
have a means of declaring that it no longer participates in a VPLS. have a means of declaring that it no longer participates in a VPLS.
To do both of these, the PE must have a means of identifying a VPLS To do both of these, the PE must have a means of identifying a VPLS
and a means by which to communicate to all other PEs. and a means by which to communicate to all other PEs.
U-PE devices also need to know what constitutes a given VPLS; U-PE devices also need to know what constitutes a given VPLS;
however, they don't need the same level of detail. The PE (or PEs) however, they don't need the same level of detail. The PE (or PEs)
to which a u-PE is connected gives the u-PE an abstraction of the to which a u-PE is connected gives the u-PE an abstraction of the
VPLS; this is described in section 5. VPLS; this is described in section 5.
3.1.2. Protocol Specification 3.1.2 Protocol Specification
The specific mechanism for autodiscovery described here is based on The specific mechanism for autodiscovery described here is based on
[3] and [7]; it uses BGP extended communities [9] to identify members [11] and [9]; it uses BGP extended communities [4] to identify
of a VPLS. A more generic autodiscovery mechanism is described in members of a VPLS. A more generic autodiscovery mechanism is
[8]. The specific extended community used is the Route Target, whose described in [8]. The specific extended community used is the Route
format is described in [9]. The semantics of the use of Route Target, whose format is described in [4]. The semantics of the use
Targets is described in [7]; their use in VPLS is identical. of Route Targets is described in [9]; their use in VPLS is identical.
As it has been assumed that VPLSs are fully meshed, a single Route As it has been assumed that VPLSs are fully meshed, a single Route
Target RT suffices for a given VPLS V, and in effect that RT is the Target RT suffices for a given VPLS V, and in effect that RT is the
identifier for VPLS V. identifier for VPLS V.
A PE announces (typically via I-BGP) that it belongs to VPLS V by A PE announces (typically via I-BGP) that it belongs to VPLS V by
annotating its NLRIs for V (see next subsection) with Route Target annotating its NLRIs for V (see next subsection) with Route Target
RT, and acts on this by accepting NLRIs from other PEs that have RT, and acts on this by accepting NLRIs from other PEs that have
Route Target RT. A PE announces that it no longer participates in V Route Target RT. A PE announces that it no longer participates in V
by withdrawing all NLRIs that it had advertised with Route Target RT. by withdrawing all NLRIs that it had advertised with Route Target RT.
3.2. Signaling 3.2 Signaling
Once discovery is done, each pair of PEs in a VPLS must be able to Once discovery is done, each pair of PEs in a VPLS must be able to
establish (and tear down) pseudowires to each other, i.e., exchange establish (and tear down) pseudowires to each other, i.e., exchange
(and withdraw) demultiplexors. This process is known as signaling. (and withdraw) demultiplexors. This process is known as signaling.
Signaling is also used to initiate "relearning", and to transmit Signaling is also used to transmit certain characteristics of the PE
certain characteristics of the PE regarding a given VPLS. regarding a given VPLS.
Recall that a demultiplexor is used to distinguish among several Recall that a demultiplexor is used to distinguish among several
different streams of traffic carried over a tunnel, each stream different streams of traffic carried over a tunnel, each stream
possibly representing a different service. In the case of VPLS, the possibly representing a different service. In the case of VPLS, the
demultiplexor not only says to which specific VPLS a packet belongs, demultiplexor not only says to which specific VPLS a packet belongs,
but also identifies the ingress PE. The former information is used but also identifies the ingress PE. The former information is used
for forwarding the packet; the latter information is used for for forwarding the packet; the latter information is used for
learning MAC addresses. The demultiplexor described here is an MPLS learning MAC addresses. The demultiplexor described here is an MPLS
label, even though the PE-to-PE tunnels may not be MPLS tunnels. label, even though the PE-to-PE tunnels may not be MPLS tunnels.
3.2.1. Setup and Teardown 3.2.1 Setup and Teardown
The VPLS BGP NLRI described below, with a new AFI and SAFI (see [6]) The VPLS BGP NLRI described below, with a new AFI and SAFI (see [3])
is used to exchange demultiplexors. is used to exchange demultiplexors.
A PE advertises a VPLS NLRI for each VPLS that it participates in. A PE advertises a VPLS NLRI for each VPLS that it participates in.
If the PE is doing learning and flooding, i.e., it is the VE, it If the PE is doing learning and flooding, i.e., it is the VE, it
announces a single set of VPLS NLRIs for each VPLS that it is in. If announces a single set of VPLS NLRIs for each VPLS that it is in. If
the PE is connected to several u-PEs, it announces one set of VPLS the PE is connected to several u-PEs, it announces one set of VPLS
NLRIs for each u-PE. A hybrid scheme is also possible, where the PE NLRIs for each u-PE. A hybrid scheme is also possible, where the PE
learns MAC addresses on some interfaces (over which it is directly learns MAC addresses on some interfaces (over which it is directly
connected to CEs) and delegates learning on other interfaces (over connected to CEs) and delegates learning on other interfaces (over
which it is connected to u-PEs). In this case, the PE would announce which it is connected to u-PEs). In this case, the PE would announce
skipping to change at page 7, line 51 skipping to change at page 10, line 21
VPLS; however, there are cases (such as a newly added PE) where the VPLS; however, there are cases (such as a newly added PE) where the
pre-existing NLRI does not have enough labels. In such cases, pre-existing NLRI does not have enough labels. In such cases,
advertising an additional NLRI for the same VPLS serves to add labels advertising an additional NLRI for the same VPLS serves to add labels
for the new PEs without disrupting service to the pre-existing PEs. for the new PEs without disrupting service to the pre-existing PEs.
If service disruption is acceptable (or when the PE restarts its BGP If service disruption is acceptable (or when the PE restarts its BGP
process), a PE MAY consider coalescing all NLRIs for a VPLS into a process), a PE MAY consider coalescing all NLRIs for a VPLS into a
single NLRI. single NLRI.
If a PE X is part of VPLS V, and X receives a VPLS NLRI for V from PE If a PE X is part of VPLS V, and X receives a VPLS NLRI for V from PE
Y that includes a demultiplexor that X can use, X sets up its ends of Y that includes a demultiplexor that X can use, X sets up its ends of
a pair of pseudowires between X and Y. X may also have to advertise a pseudowire between X and Y. X may also have to advertise a new
a new NLRI for V that includes a demultiplexor that Y can use, if its NLRI for V that includes a demultiplexor that Y can use, if its
pre-existing NLRI for V did not include a demultiplexor for Y. pre-existing NLRI for V did not include a demultiplexor for Y.
If Y's configuration is changed to remove it from VPLS V, then Y MUST If Y's configuration is changed to remove it from VPLS V, then Y MUST
withdraw all its NLRIs for V. If all Y's links to CEs in V go down, withdraw all its NLRIs for V. If all Y's links to CEs in V go down,
then Y SHOULD either withdraw all its NLRIs for V, or let other PEs then Y SHOULD either withdraw all its NLRIs for V, or let other PEs
in the VPLS V know in some way that Y is no longer connected to its in the VPLS V know in some way that Y is no longer connected to its
CEs. CEs.
If Y withdraws an NLRI for V that X was using, then X MUST tear down If Y withdraws an NLRI for V that X was using, then X MUST tear down
its ends of the pseudowires between X and Y. its ends of the pseudowire between X and Y.
The format of the VPLS NLRI is given below. The AFI and SAFI are the
same as for the L2 VPN NLRI [3].
Figure 2: BGP NLRI for VPLS Information The format of the VPLS NLRI is given below. The AFI is to be
assigned by IANA, and the SAFI is the VPLS SAFI (65).
+------------------------------------+ +------------------------------------+
| Length (2 octets) | | Length (2 octets) |
+------------------------------------+ +------------------------------------+
| Route Distinguisher (8 octets) | | Route Distinguisher (8 octets) |
+------------------------------------+ +------------------------------------+
| VE ID (2 octets) | | VE ID (2 octets) |
+------------------------------------+ +------------------------------------+
| VE Block Offset (2 octets) | | VE Block Offset (2 octets) |
+------------------------------------+ +------------------------------------+
| VE Block Size (2 octets) | | VE Block Size (2 octets) |
+------------------------------------+ +------------------------------------+
| Label Base (3 octets) | | Label Base (3 octets) |
+------------------------------------+ +------------------------------------+
3.2.2. Signaling PE Capabilities Figure 2: BGP NLRI for VPLS Information
3.2.2 Signaling PE Capabilities
The Encaps Type and Control Flags are encoded in an extended The Encaps Type and Control Flags are encoded in an extended
attribute. The community type also is used in L2 VPNs [3]. attribute.
The Encaps Type for VPLS is 19. The Encaps Type for VPLS is 19.
Figure 4: Control Flags Bit Vector
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |P|Q|F|C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
Figure 3: layer2-info extended community
+------------------------------------+ +------------------------------------+
| Extended community type (2 octets) | | Extended community type (2 octets) |
+------------------------------------+ +------------------------------------+
| Encaps Type (1 octet) | | Encaps Type (1 octet) |
+------------------------------------+ +------------------------------------+
| Control Flags (1 octet) | | Control Flags (1 octet) |
+------------------------------------+ +------------------------------------+
| Layer-2 MTU (2 octet) | | Layer-2 MTU (2 octet) |
+------------------------------------+ +------------------------------------+
| Reserved (2 octets) | | Reserved (2 octets) |
+------------------------------------+ +------------------------------------+
Figure 3: Layer2 Info Extended Community
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
Figure 4: Control Flags Bit Vector
With reference to Figure 4, the following bits are defined; the MBZ With reference to Figure 4, the following bits are defined; the MBZ
bits MUST be set to zero. bits MUST be set to zero.
Name Meaning Name Meaning
P If set to 1, then the PE will strip the outermost VLAN
tag from the customer frame on ingress, and push a
VLAN tag on egress. If set to 0, the customer frame
is left unchanged.
Q Reserved.
F If set to 1 (0), the PE is (not) capable of flooding.
C If set to 1 (0), Control word is (not) required when C If set to 1 (0), Control word is (not) required when
encapsulating Layer 2 frames [10]. encapsulating Layer 2 frames [10].
S If set to 1 (0), Sequenced delivery of frames is (not) S If set to 1 (0), Sequenced delivery of frames is (not)
required. required.
3.3. Multi-AS VPLS 3.3 Multi-AS VPLS
As in [3] and [7], the above autodiscovery and signaling functions As in [11] and [9], the above autodiscovery and signaling functions
are typically announced via I-BGP. This assumes that all the sites are typically announced via I-BGP. This assumes that all the sites
in a VPLS are connected to PEs in a single Autonomous System (AS). in a VPLS are connected to PEs in a single Autonomous System (AS).
However, sites in a VPLS may connect to PEs in different ASes. This However, sites in a VPLS may connect to PEs in different ASes. This
leads to two issues: 1) there would not be an I-BGP connection leads to two issues: 1) there would not be an I-BGP connection
between those PEs, so some means of signaling across ASes may be between those PEs, so some means of signaling across ASes may be
needed; and 2) there may not be PE-to-PE tunnels between the ASes. needed; and 2) there may not be PE-to-PE tunnels between the ASes.
A similar problem is solved in [7], Section 10. Three methods are A similar problem is solved in [9], Section 10. Three methods are
suggested to address issue (1); all these methods have analogs in suggested to address issue (1); all these methods have analogs in
multi-AS VPLS. multi-AS VPLS.
Here is a diagram for reference: Here is a diagram for reference:
__________ ____________ ____________ __________ __________ ____________ ____________ __________
/ \ / \ / \ / \ / \ / \ / \ / \
\___/ AS 1 \ / AS 2 \___/ \___/ AS 1 \ / AS 2 \___/
\ / \ /
+-----+ +-------+ | +-------+ +-----+ +-----+ +-------+ | +-------+ +-----+
| PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 | | PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 |
+-----+ +-------+ | +-------+ +-----+ +-----+ +-------+ | +-------+ +-----+
___ / \ ___ ___ / \ ___
/ \ / \ / \ / \ / \ / \
\__________/ \____________/ \____________/ \__________/ \__________/ \____________/ \____________/ \__________/
a) VPLS-to-VPLS connections at the AS border routers.
Figure 6: Inter-AS VPLS
3.3.1 a) VPLS-to-VPLS connections at the AS border routers.
In this method, an AS Border Router (ASBR1) acts as a PE for all In this method, an AS Border Router (ASBR1) acts as a PE for all
VPLSs that span AS1 and an AS to which ASBR1 is connected, such as VPLSs that span AS1 and an AS to which ASBR1 is connected, such as
AS2 here. The ASBR on the neighboring AS (ASBR2) is viewed by AS2 here. The ASBR on the neighboring AS (ASBR2) is viewed by ASBR1
ASBR1 as a CE for the VPLSs that span AS1 and AS2; similarly, as a CE for the VPLSs that span AS1 and AS2; similarly, ASBR2 acts as
ASBR2 acts as a PE for this VPLS from AS2's point of view, and a PE for this VPLS from AS2's point of view, and views ASBR1 as a CE.
views ASBR1 as a CE.
This method does not require MPLS on the ASBR1-ASBR2 link, but This method does not require MPLS on the ASBR1-ASBR2 link, but does
does require that this link carry Ethernet traffic, and that there require that this link carry Ethernet traffic, and that there be a
be a separate VLAN sub-interface for each VPLS traversing this separate VLAN sub-interface for each VPLS traversing this link. It
link. It further requires that ASBR1 does the PE operations further requires that ASBR1 does the PE operations (discovery,
(discovery, signaling, MAC address learning, flooding, signaling, MAC address learning, flooding, encapsulation, etc.) for
encapsulation, etc.) for all VPLSs that traverse ASBR1. This all VPLSs that traverse ASBR1. This imposes a significant burden on
imposes a significant burden on ASBR1, both on the control plane ASBR1, both on the control plane and the data plane, which limits the
and the data plane, which limits the number of multi-AS VPLSs. number of multi-AS VPLSs.
Note that in general, there will be multiple connections between a Note that in general, there will be multiple connections between a
pair of ASes, for redundancy. In this case, the Spanning Tree pair of ASes, for redundancy. In this case, the Spanning Tree
Protocol must be run on each VPLS that spans these ASes, so that a Protocol (STP), or some other means of loop detection and prevention,
loop-free topology can be constructed in each VPLS. This imposes must be run on each VPLS that spans these ASes, so that a loop-free
a further burden on the ASBRs and PEs participating in those topology can be constructed in each VPLS. This imposes a further
VPLSs, as these devices would need to run the Spanning Tree burden on the ASBRs and PEs participating in those VPLSs, as these
Protocol for each such VPLS.. devices would need to run a loop detection algorithm for each such
VPLS. How this may be achieved is outside the scope of this
document.
b) EBGP redistribution of VPLS information between ASBRs. 3.3.2 b) EBGP redistribution of VPLS information between ASBRs.
This method requires I-BGP peerings between the PEs in AS1 and This method requires I-BGP peerings between the PEs in AS1 and ASBR1
ASBR1 in AS1 (perhaps via route reflectors), an E-BGP peering in AS1 (perhaps via route reflectors), an E-BGP peering between ASBR1
between ASBR1 and ASBR2 in AS2, and I-BGP peerings between ASBR2 and ASBR2 in AS2, and I-BGP peerings between ASBR2 and the PEs in
and the PEs in AS2. In the above example, PE1 sends a VPLS NLRI AS2. In the above example, PE1 sends a VPLS NLRI to ASBR1 with a
to ASBR1 with a label block and itself as the BGP nexthop; ASBR1 label block and itself as the BGP nexthop; ASBR1 sends the NLRI to
sends the NLRI to ASBR2 with new labels and itself as the BGP ASBR2 with new labels and itself as the BGP nexthop; and ASBR2 sends
nexthop; and ASBR2 sends the NLRI to PE2 with new labels and the NLRI to PE2 with new labels and itself as the nexthop.
itself as the nexthop.
The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2 The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2
sends to PE2) is identical to the VPLS NLRI that PE1 sends to sends to PE2) is identical to the VPLS NLRI that PE1 sends to ASBR1,
ASBR1, except for the label block. To be precise, the Length, the except for the label block. To be precise, the Length, the Route
Route Distinguisher, the VE ID, the VE Block Offset, and the VE Distinguisher, the VE ID, the VE Block Offset, and the VE Block Size
Block Size MUST be the same; the Label Base may be different. MUST be the same; the Label Base may be different. Furthermore,
Furthermore, ASBR1 must also update its forwarding path as ASBR1 must also update its forwarding path as follows: if the Label
follows: if the Label Base sent by PE1 is L1, the Label-block Size Base sent by PE1 is L1, the Label-block Size is N, the Label Base
is N, the Label Base sent by ASBR1 is L2, and the tunnel label sent by ASBR1 is L2, and the tunnel label from ASBR1 to PE1 is T,
from ASBR1 to PE1 is T, then ASBR1 must install the following in then ASBR1 must install the following in the forwarding path:
the forwarding path:
swap L2 with L1 and push T, swap L2 with L1 and push T,
swap L2+1 with L1+1 and push T, swap L2+1 with L1+1 and push T, ...
...
swap L2+N-1 with L1+N-1 and push T. swap L2+N-1 with L1+N-1 and push T.
ASBR2 must act similarly, except that it may not need a tunnel ASBR2 must act similarly, except that it may not need a tunnel label
label if it is directly connected with ASBR1. if it is directly connected with ASBR1.
When PE2 wants to send a VPLS packet to PE1, PE2 uses its VE ID to When PE2 wants to send a VPLS packet to PE1, PE2 uses its VE ID to
get the right VPLS label from ASBR2's label block for PE1, and get the right VPLS label from ASBR2's label block for PE1, and uses a
uses a tunnel label to reach ASBR2. ASBR2 swaps the VPLS label tunnel label to reach ASBR2. ASBR2 swaps the VPLS label with the
with the label from ASBR1; ASBR1 then swaps the VPLS label with label from ASBR1; ASBR1 then swaps the VPLS label with the label from
the label from PE1, and pushes a tunnel label to reach PE1. PE1, and pushes a tunnel label to reach PE1.
In this method, one needs MPLS on the ASBR1-ASBR2 interface, but In this method, one needs MPLS on the ASBR1-ASBR2 interface, but
there is no requirement that the link layer be Ethernet. there is no requirement that the link layer be Ethernet.
Furthermore, the ASBRs take part in distributing VPLS information. Furthermore, the ASBRs take part in distributing VPLS information.
However, the data plane requirements of the ASBRs is much simpler However, the data plane requirements of the ASBRs is much simpler
than in method (a), being limited to label operations. Finally, than in method (a), being limited to label operations. Finally, the
the construction of loop-free VPLS topologies is done by routing construction of loop-free VPLS topologies is done by routing
decisions, viz. BGP path and nexthop selection, so there is no decisions, viz. BGP path and nexthop selection, so there is no need
need to run the Spanning Tree Protocol on a per-VPLS basis. Thus, to run the Spanning Tree Protocol on a per-VPLS basis. Thus, this
this method is considerably more scalable than method (a). method is considerably more scalable than method (a).
c) Multi-hop EBGP redistribution of VPLS information between ASes. 3.3.3 c) Multi-hop EBGP redistribution of VPLS information between
ASes.
In this method, there is a multi-hop E-BGP peering between the PEs In this method, there is a multi-hop E-BGP peering between the PEs
(or preferably, a Route Reflector) in AS1 and the PEs (or Route (or preferably, a Route Reflector) in AS1 and the PEs (or Route
Reflector) in AS2. PE1 sends a VPLS NLRI with labels and nexthop Reflector) in AS2. PE1 sends a VPLS NLRI with labels and nexthop
self to PE2; if this is via route reflectors, the BGP nexthop is self to PE2; if this is via route reflectors, the BGP nexthop is not
not changed. This requires that there be a tunnel LSP from PE1 to changed. This requires that there be a tunnel LSP from PE1 to PE2.
PE2. This tunnel LSP can be created exactly as in [7], section 10 This tunnel LSP can be created exactly as in [9], section 10 (c), for
(c), for example using E-BGP to exchange labeled IPv4 routes for example using E-BGP to exchange labeled IPv4 routes for the PE
the PE loopbacks. loopbacks.
When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS label
label corresponding to its own VE ID onto the packet. It then corresponding to its own VE ID onto the packet. It then pushes the
pushes the tunnel label(s) to reach PE2. tunnel label(s) to reach PE2.
This method requires no VPLS information (in either the control or This method requires no VPLS information (in either the control or
the data plane) on the ASBRs. The ASBRs only need to set up the data plane) on the ASBRs. The ASBRs only need to set up PE-to-PE
PE-to-PE tunnel LSPs in the control plane, and do label operations tunnel LSPs in the control plane, and do label operations in the data
in the data plane. Again, as in the case of method (b), the plane. Again, as in the case of method (b), the construction of
construction of loop-free VPLS topologies is done by routing loop-free VPLS topologies is done by routing decisions, i.e., BGP
decisions, i.e., BGP path and nexthop selection, so there is no path and nexthop selection, so there is no need to run the Spanning
need to run the Spanning Tree Protocol on a per-VPLS basis. This Tree Protocol on a per-VPLS basis. This option is likely to be the
option is likely to be the most scalable of the three methods most scalable of the three methods presented here.
presented here.
In order to ease the allocation of VE IDs for a VPLS that spans In order to ease the allocation of VE IDs for a VPLS that spans
multiple ASes, one can allocate ranges for each AS. For example, AS1 multiple ASes, one can allocate ranges for each AS. For example, AS1
uses VE IDs in the range 1 to 100, AS2 from 101 to 200, etc. If uses VE IDs in the range 1 to 100, AS2 from 101 to 200, etc. If
there are 10 sites attached to AS1 and 20 to AS2, the allocated VE there are 10 sites attached to AS1 and 20 to AS2, the allocated VE
IDs could be 1-10 and 101 to 120. This minimizes the number of VPLS IDs could be 1-10 and 101 to 120. This minimizes the number of VPLS
NLRIs that are exchanged while ensuring that VE IDs are kept unique. NLRIs that are exchanged while ensuring that VE IDs are kept unique.
In the above example, if AS1 needed more than 100 sites, then another In the above example, if AS1 needed more than 100 sites, then another
range can be allocated to AS1. The only caveat is that there is no range can be allocated to AS1. The only caveat is that there is no
overlap between VE ID ranges among ASes. The exception to this rule overlap between VE ID ranges among ASes. The exception to this rule
is multi-homing, which is dealt with below. is multi-homing, which is dealt with below.
3.4. Multi-homing and Path Selection 3.4 Multi-homing and Path Selection
It is often desired to multi-home a VPLS site, i.e., to connect it to It is often desired to multi-home a VPLS site, i.e., to connect it to
multiple PEs, perhaps even in different ASes. In such a case, the multiple PEs, perhaps even in different ASes. In such a case, the
PEs connected to the same site can either be configured with the same PEs connected to the same site can either be configured with the same
VE ID or with different VE IDs. In the latter case, it is mandatory VE ID or with different VE IDs. In the latter case, it is mandatory
to run STP on the CE device, and possibly on the PEs, to construct a to run STP on the CE device, and possibly on the PEs, to construct a
loop-free VPLS topology. loop-free VPLS topology. How this can be accomplished is outside the
scope of this document; however, the rest of this section will
describe in some detail the former case.
In the case where the PEs connected to the same site are assigned the In the case where the PEs connected to the same site are assigned the
same VE ID, a loop-free topology is constructed by routing same VE ID, a loop-free topology is constructed by routing
mechanisms, in particular, by BGP path selection. When a BGP speaker mechanisms, in particular, by BGP path selection. When a BGP speaker
receives two equivalent NLRIs (see below for the definition), it receives two equivalent NLRIs (see below for the definition), it
applies standard path selection criteria such as Local Preference and applies standard path selection criteria such as Local Preference and
AS Path Length to determine which NLRI to choose; it MUST pick only AS Path Length to determine which NLRI to choose; it MUST pick only
one. If the chosen NLRI is subsequently withdrawn, the BGP speaker one. If the chosen NLRI is subsequently withdrawn, the BGP speaker
applies path selection to the remaining equivalent VPLS NLRIs to pick applies path selection to the remaining equivalent VPLS NLRIs to pick
another; if none remain, the forwarding information associated with another; if none remain, the forwarding information associated with
that NLRI is removed. that NLRI is removed.
Two VPLS NLRIs are considered equivalent from a path selection point Two VPLS NLRIs are considered equivalent from a path selection point
of view if the Route Distinguisher, the VE ID and the VE Block Offset of view if the Route Distinguisher, the VE ID and the VE Block Offset
are the same. If two PEs are assigned the same VE ID in a given are the same. If two PEs are assigned the same VE ID in a given
VPLS, they MUST use the same Route Distinguisher, and they MUST VPLS, they MUST use the same Route Distinguisher, and they SHOULD
announce the same VE Block Size for a given VE Offset. announce the same VE Block Size for a given VE Offset.
4. Data Plane 4. Data Plane
This section discusses two aspects of the data plane for PEs and u- This section discusses two aspects of the data plane for PEs and
PEs implementing VPLS: encapsulation and forwarding. u-PEs implementing VPLS: encapsulation and forwarding.
4.1. Encapsulation 4.1 Encapsulation
Ethernet frames received from CE devices are encapsulated for Ethernet frames received from CE devices are encapsulated for
transmission over the packet switched network connecting the PEs. transmission over the packet switched network connecting the PEs.
The encapsulation is as in [10], with one change: a PE that sets the The encapsulation is as in [10], with one change: a PE that sets the
P bit in the Control Flags strips the outermost VLAN from an Ethernet P bit in the Control Flags strips the outermost VLAN from an Ethernet
frame received from a CE before encapsulating it, and pushes a VLAN frame received from a CE before encapsulating it, and pushes a VLAN
onto a decapsulated frame before sending it to a CE. onto a decapsulated frame before sending it to a CE.
4.2. Forwarding 4.2 Forwarding
Forwarding of VPLS packets is based on the interface over which the VPLS packets are classified as belonging to a given service instance
packet is received, which determines which VPLS the packet belongs and associated forwarding table based on the interface over which the
to, and the destination MAC address. The former mapping is packet is received. Packets are forwarded in the context of the
determined by configuration. The latter is the focus of this service instance based on the destination MAC address. The former
section. mapping is determined by configuration. The latter is the focus of
this section.
4.2.1. MAC address learning 4.2.1 MAC address learning
As was mentioned earlier, the key distinguishing feature of VPLS is As was mentioned earlier, the key distinguishing feature of VPLS is
that it is a multipoint service. This means that the entire Service that it is a multipoint service. This means that the entire Service
Provider network should appear as a single logical learning bridge Provider network should appear as a single logical learning bridge
for each VPLS that the SP network supports. The logical ports for for each VPLS that the SP network supports. The logical ports for
the SP "bridge" are the connections from the SP edge, be it a PE or a the SP "bridge" are the customer ports on all of the VE on a given
u-PE, to the CE. Just as a learning bridge learns MAC addresses on service. Just as a learning bridge learns MAC addresses on its
its ports, the SP bridge must learn MAC addresses at its VEs. ports, the SP bridge must learn MAC addresses at its VEs.
Learning consists of associating source MAC addresses of packets with Learning consists of associating source MAC addresses of packets with
the (logical) ports on which they arrive; this association is the the (logical) ports on which they arrive; this association is the
Forwarding Information Base (FIB). The FIB is used for forwarding Forwarding Information Base (FIB). The FIB is used for forwarding
packets. For example, suppose the bridge receives a packet with packets. For example, suppose the bridge receives a packet with
source MAC address S on (logical) port P. If subsequently, the source MAC address S on (logical) port P. If subsequently, the
bridge receives a packet with destination MAC address S, it knows bridge receives a packet with destination MAC address S, it knows
that it should send the packet out on port P. that it should send the packet out on port P.
There are two modes of learning: qualified and unqualified learning. 4.2.2 Flooding
In qualified learning, the learning decisions at the VE are based on
the customer ethernet packet's MAC address and VLAN tag, if one
exists. This VLAN is often called the "service delimiting VLAN".
Each VLAN on a given port is mapped to a different service (VPLS, IP
VPN, point-to-point Layer 2 VPN, etc.); each VLAN that is mapped to a
VPLS service has its own VPLS FIB.
In unqualified learning, learning is based on a customer ethernet
packet's MAC address only. This is also called "port-mode VPLS".
4.2.2. Flooding
When a bridge receives a packet to a destination that is not in its When a bridge receives a packet to a destination that is not in its
FIB, it floods the packet on all the other ports. Similarly, a VE FIB, it floods the packet on all the other ports. Similarly, a VE
will flood packets to an unknown destination to all other VEs in the will flood packets to an unknown destination to all other VEs in the
VPLS. VPLS.
In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the
destination MAC address on the frame was not in PE2's FIB (for that destination MAC address on the frame was not in PE2's FIB (for that
VPLS), then PE2 would be responsible for flooding that frame to every VPLS), then PE2 would be responsible for flooding that frame to every
other PE in the same VPLS. On receiving that frame, PE1 would be other PE in the same VPLS. On receiving that frame, PE1 would be
skipping to change at page 14, line 30 skipping to change at page 18, line 20
knew which CE "owned" that MAC address). knew which CE "owned" that MAC address).
On the other hand, if PE3 received the frame, it could delegate On the other hand, if PE3 received the frame, it could delegate
further flooding of the frame to its u-PE. If PE3 was connected to 2 further flooding of the frame to its u-PE. If PE3 was connected to 2
u-PEs, it would announce that it has two u-PEs. PE3 could either u-PEs, it would announce that it has two u-PEs. PE3 could either
announce that it is incapable of flooding, in which case it would announce that it is incapable of flooding, in which case it would
receive two frames, one for each u-PE, or it could announce that it receive two frames, one for each u-PE, or it could announce that it
is capable of flooding, in which case it would receive one copy of is capable of flooding, in which case it would receive one copy of
the frame, which it would then send to both u-PEs. the frame, which it would then send to both u-PEs.
4.2.3. "Split Horizon" Flooding 4.2.3 "Split Horizon" Forwarding
When a PE capable of flooding receives a broadcast Ethernet frame, or When a PE capable of flooding receives a broadcast Ethernet frame, or
one with an unknown destination MAC address, it must flood the frame. one with an unknown destination MAC address, it must flood the frame.
If the frame arrived from an attached CE, the PE must send a copy of If the frame arrived from an attached CE, the PE must send a copy of
the frame to every other attached CE, as well as to all PEs the frame to every other attached CE, as well as to all PEs
participating in the VPLS. If the frame arrived from another PE, participating in the VPLS. If the frame arrived from another PE,
however, the PE must only send a copy of the packet to attached CEs. however, the PE must only send a copy of the packet to attached CEs.
The PE MUST NOT send the frame to other PEs. This notion has been The PE MUST NOT send the frame to other PEs. This notion has been
termed "split horizon" flooding, and is a consequence of the PEs termed "split horizon" forwarding, and is a consequence of the PEs
being logically full-meshed -- if a broadcast frame is received from being logically full-meshed -- if a broadcast frame is received from
PEx, then PEx would have sent a copy to all other PEs. PEx, then PEx would have sent a copy to all other PEs.
Split horizon forwarding rules also apply to multicast frames (i.e.,
those with a multicast destination MAC address). In this case, when
a PE receives a multicast frame from another PE, the frame is
replicated and sent to the relevant subset of attached CEs; however,
it MUST NOT be sent to other PEs.
5. Deployment Options 5. Deployment Options
In deploying a network that supports VPLS, the SP must decide whether In deploying a network that supports VPLS, the SP must decide what
the VPLS-aware device closest to the customer (the VE) is a u-PE or a functions the VPLS-aware device closest to the customer (the VE)
PE. The default case described in this document is that the VE is a supports. The default case described in this document is that the VE
PE. However, there are a number of reasons that the VE might be a u- is a PE. However, there are a number of reasons that the VE might be
PE, i.e., a device that does layer 2 functions such as MAC address a device that does all the Layer 2 functions (such as MAC address
learning and flooding, and some limited layer 3 functions such as learning and flooding), and a limited set of Layer 3 functions (such
communicating to its PE, but doesn't do full-fledged discovery and as communicating to its PE), but, for example, doesn't do
PE-to-PE signaling. full-fledged discovery and PE-to-PE signaling. Such a device is
called a "u-PE".
As both of these cases have benefits, one would like to be able to As both of these cases have benefits, one would like to be able to
"mix and match" these scenarios. The signaling mechanism presented "mix and match" these scenarios. The signaling mechanism presented
here allows this. PE1 may be directly connected to CE devices; PE2 here allows this. For example, in a given provider network, one PE
may be connected to u-PEs that are connected to CEs; and PE3 may be may be directly connected to CE devices; another may be connected to
connected directly to a customer over some interfaces and to u-PEs u-PEs that are connected to CEs; and a third may be connected
over others. All these PEs do discovery and signaling in the same directly to a customer over some interfaces and to u-PEs over others.
manner. How they do learning and forwarding depends on whether or All these PEs perform discovery and signaling in the same manner.
not there is a u-PE; however, this is a local matter, and is not How they do learning and forwarding depends on whether or not there
signaled. is a u-PE; however, this is a local matter, and is not signaled.
However, the details of the operation of a u-PE and its interactions
6. Normative References with PEs and other u-PEs is beyond the scope of this document.
[ 1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[ 6] Bates, T., Rekhter, Y., Chandra, R., and Katz, D.,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000
[ 9] Sangli, S., D. Tappan, and Y. Rekhter, "BGP Extended Communities
Attribute", draft-ietf-idr-bgp-ext-communities-07.txt (work in
progress)
[10] Martini, L., et al, "Encapsulation Methods for Transport of
Ethernet Frames Over IP/MPLS Networks", draft-ietf-
pwe3-ethernet-encap-06.txt (work in progress)
[11] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option," RFC 2385, August 1998
7. Informative References
[ 2] Andersson, L., and Rosen, E., "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-04.txt
(work in progress)
[ 3] Kompella, K., (Editor), "Layer 2 VPNs Over Tunnels", draft-
kompella-l2vpn-l2vpn-00.txt (work in progress)
[ 4] Martini, L., et al, "Pseudowire Setup and Maintenance using LDP"
draft-ietf-pwe3-control-protocol-06.txt (work in progress)
[ 5] Kompella, V., et al, "Virtual Private LAN Services over MPLS",
draft-ietf-ppvpn-vpls-ldp-03.txt (work in progress)
[ 7] Rosen, E., and Rekhter, Y., Editors, "BGP/MPLS VPNs", draft-
ietf-l3vpn-rfc2547bis-01.txt (work in progress)
[ 8] Ould-Brahim, H., Rosen, E., and Rekhter, Y., "Using BGP as an
Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", draft-
ietf-l3vpn-bgpvpn-auto-04.txt (work in progress)
Security Considerations 6. Security Considerations
The focus in Virtual Private LAN Service is the privacy of data, The focus in Virtual Private LAN Service is the privacy of data,
i.e., that data in a VPLS is only distributed to other nodes in that i.e., that data in a VPLS is only distributed to other nodes in that
VPLS and not to any external agent or other VPLS. Note that VPLS VPLS and not to any external agent or other VPLS. Note that VPLS
does not offer security or authentication: VPLS packets are sent in does not offer security or authentication: VPLS packets are sent in
the clear in the packet-switched network, and a man-in-the-middle can the clear in the packet-switched network, and a man-in-the-middle can
eavesdrop, and may be able to inject packets into the data stream. eavesdrop, and may be able to inject packets into the data stream.
If security is desired, the PE-to-PE tunnels can be IPsec tunnels. If security is desired, the PE-to-PE tunnels can be IPsec tunnels.
For more security, the end systems in the VPLS sites can use For more security, the end systems in the VPLS sites can use
appropriate means of encryption to secure their data even before it appropriate means of encryption to secure their data even before it
enters the Service Provider network. enters the Service Provider network.
There are two aspects to achieving data privacy in a VPLS: securing There are two aspects to achieving data privacy in a VPLS: securing
the control plane, and protecting the forwarding path. Compromise of the control plane, and protecting the forwarding path. Compromise of
the control plane could result in a PE sending data belonging to some the control plane could result in a PE sending data belonging to some
VPLS to another VPLS, or blackholing VPLS data, or even sending it to VPLS to another VPLS, or blackholing VPLS data, or even sending it to
an eavesdropper, none of which are acceptable from a data privacy an eavesdropper, none of which are acceptable from a data privacy
point of view. Since all control plane exchanges are via BGP, point of view. Since all control plane exchanges are via BGP,
techniques such as in [11] help authenticate BGP messages, making it techniques such as in [2] help authenticate BGP messages, making it
harder to spoof updates (which can be used to divert VPLS traffic to harder to spoof updates (which can be used to divert VPLS traffic to
the wrong VPLS), or withdraws (denial of service attacks). In the the wrong VPLS), or withdraws (denial of service attacks). In the
multi-AS options (b) and (c), this also means protecting the inter-AS multi-AS options (b) and (c), this also means protecting the inter-AS
BGP sessions, between the ASBRs, the PEs or the Route Reflectors. BGP sessions, between the ASBRs, the PEs or the Route Reflectors.
Note that [11] will not help in keeping VPLS labels private -- Note that [2] will not help in keeping VPLS labels private -- knowing
knowing the labels, one can eavesdrop on VPLS traffic. However, this the labels, one can eavesdrop on VPLS traffic. However, this
requires access to the data path within a Service Provider network. requires access to the data path within a Service Provider network.
Protecting the data plane requires ensuring that PE-to-PE tunnels are Protecting the data plane requires ensuring that PE-to-PE tunnels are
well-behaved (this is outside the scope of this document), and that well-behaved (this is outside the scope of this document), and that
VPLS labels are accepted only from valid interfaces. For a PE, valid VPLS labels are accepted only from valid interfaces. For a PE, valid
interfaces comprise links from P routers. For an ASBR, a valid interfaces comprise links from P routers. For an ASBR, a valid
interface is a link from an ASBR in an AS that is part of a given interface is a link from an ASBR in an AS that is part of a given
VPLS. It is especially important in the case of multi-AS VPLSs that VPLS. It is especially important in the case of multi-AS VPLSs that
one accept VPLS packets only from valid interfaces. one accept VPLS packets only from valid interfaces.
IANA Considerations 7. IANA Considerations
IANA is asked to allocate an AFI for Layer 2 information (suggested IANA is asked to allocate an AFI for Layer 2 information (suggested
value: 25). value: 25).
Contributors 8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[3] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol
Extensions for BGP-4", RFC 2858, June 2000.
[4] Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities
Attribute",
Internet-Draft draft-ietf-idr-bgp-ext-communities-08, February
2005.
[5] Martini, L., Rosen, E., El-Aawar, N. and G. Heron,
"Encapsulation Methods for Transport of Ethernet Frames Over
IP/MPLS Networks",
Internet-Draft draft-ietf-pwe3-ethernet-encap-08, September
2004.
8.2 Informative References
[6] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)",
Internet-Draft draft-ietf-l2vpn-l2-framework-05, June 2004.
[7] Lasserre, M. and V. Kompella, "Virtual Private LAN Services
over MPLS", Internet-Draft draft-ietf-l2vpn-vpls-ldp-05,
September 2004.
[8] Ould-Brahim, H., Rosen, E. and Y. Rekhter, "Using BGP as an
Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs",
Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-04, May 2004.
[9] Rosen, E., "BGP/MPLS IP VPNs",
Internet-Draft draft-ietf-l3vpn-rfc2547bis-03, October 2004.
[10] Martini, L., "Pseudowire Setup and Maintenance using LDP",
Internet-Draft draft-ietf-pwe3-control-protocol-14, November
2004.
[11] Kompella, K., "Layer 2 VPNs Over Tunnels",
Internet-Draft draft-kompella-l2vpn-l2vpn-00, January 2004.
Authors' Addresses
Kireeti Kompella (editor)
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: kireeti@juniper.net
Yakov Rekhter (editor)
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: kireeti@juniper.net
Appendix A. Contributors
The following contributed to this document: The following contributed to this document:
Javier Achirica, Telefonica Javier Achirica, Telefonica
Loa Andersson, TLA Loa Andersson, Acreo
Chaitanya Kodeboyina, Juniper Chaitanya Kodeboyina, Juniper
Giles Heron, Consultant Giles Heron, Alcatel
Sunil Khandekar, Alcatel Sunil Khandekar, Alcatel
Vach Kompella, Alcatel Vach Kompella, Alcatel
Marc Lasserre, Riverstone Marc Lasserre, Riverstone
Pierre Lin, Yipes Pierre Lin
Pascal Menezes, Terabeam Pascal Menezes
Ashwin Moranganti, Appian Ashwin Moranganti, Appian
Hamid Ould-Brahim, Nortel Hamid Ould-Brahim, Nortel
Seo Yeong-il, Korea Tel Seo Yeong-il, Korea Tel
Acknowledgments Appendix B. Acknowledgements
Thanks to Joe Regan and Alfred Nothaft for their contributions.
Authors' Addresses
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
kireeti@juniper.net
Yakov Rekhter Thanks to Joe Regan and Alfred Nothaft for their contributions. Many
Juniper Networks thanks too to Eric Ji, Chaitanya Kodeboyina, and Mike Loomis for
1194 N. Mathilda Ave their detailed reviews.
Sunnyvale, CA 94089
yakov@juniper.net
IPR Notice Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject Disclaimer of Validity
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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/