draft-ietf-l2vpn-vpls-bgp-08.txt   rfc4761.txt 
Network Working Group K. Kompella, Ed. Network Working Group K. Kompella, Ed.
Internet-Draft Y. Rekhter, Ed. Request for Comments: 4761 Y. Rekhter, Ed.
Expires: December 23, 2006 Juniper Networks Category: Standards Track Juniper Networks
June 21, 2006 January 2007
Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and
Signaling
draft-ietf-l2vpn-vpls-bgp-08
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Virtual Private LAN Service (VPLS)
Task Force (IETF), its areas, and its working groups. Note that Using BGP for Auto-Discovery and Signaling
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/1id-abstracts.txt. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2006. Copyright (C) The IETF Trust (2007).
Copyright Notice IESG Note
Copyright (C) The Internet Society (2006). The L2VPN Working Group produced two separate documents, RFC 4762 and
this document, that ultimately perform similar functions in different
manners. Be aware that each method is commonly referred to as "VPLS"
even though they are distinct and incompatible with one another.
Abstract Abstract
Virtual Private LAN (Local Area Network) Service (VPLS), also known Virtual Private LAN Service (VPLS), also known as Transparent LAN
as Transparent LAN Service, and Virtual Private Switched Network Service and Virtual Private Switched Network service, is a useful
service, is a useful Service Provider offering. The service offers a Service Provider offering. The service offers a Layer 2 Virtual
Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, Private Network (VPN); however, in the case of VPLS, the customers in
the customers in the VPN are connected by a multipoint Ethernet LAN, the VPN are connected by a multipoint Ethernet LAN, in contrast to
in contrast to the usual Layer 2 VPNs, which are point-to-point in the usual Layer 2 VPNs, which are point-to-point in nature.
nature.
This document describes the functions required to offer VPLS, a This document describes the functions required to offer VPLS, a
mechanism for signaling a VPLS, and rules for forwarding VPLS frames mechanism for signaling a VPLS, and rules for forwarding VPLS frames
across a packet switched network. across a packet switched network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4 1.1. Scope of This Document .....................................3
1.2. Conventions used in this document . . . . . . . . . . . . 5 1.2. Conventions Used in This Document ..........................4
1.3. Changes from version 06 to 07 . . . . . . . . . . . . . . 5 2. Functional Model ................................................4
1.4. Changes from version 05 to 06 . . . . . . . . . . . . . . 6 2.1. Terminology ................................................5
1.5. Changes from version 04 to 05 . . . . . . . . . . . . . . 6 2.2. Assumptions ................................................5
1.6. Changes from version 03 to 04 . . . . . . . . . . . . . . 7 2.3. Interactions ...............................................6
2. Functional Model . . . . . . . . . . . . . . . . . . . . . . . 8 3. Control Plane ...................................................6
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Auto-Discovery .............................................7
2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. Functions ...........................................7
2.3. Interactions . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Protocol Specification ..............................7
3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Signaling ..................................................8
3.1. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Label Blocks ........................................8
3.1.1. Functions . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. VPLS BGP NLRI .......................................9
3.1.2. Protocol Specification . . . . . . . . . . . . . . . . 12 3.2.3. PW Setup and Teardown ..............................10
3.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. Signaling PE Capabilities ..........................10
3.2.1. Label Blocks . . . . . . . . . . . . . . . . . . . . . 13 3.3. BGP VPLS Operation ........................................11
3.2.2. VPLS BGP NLRI . . . . . . . . . . . . . . . . . . . . 13 3.4. Multi-AS VPLS .............................................13
3.2.3. PW Setup and Teardown . . . . . . . . . . . . . . . . 14 3.4.1. Method (a): VPLS-to-VPLS Connections at the ASBRs ..13
3.2.4. Signaling PE Capabilities . . . . . . . . . . . . . . 15 3.4.2. Method (b): EBGP Redistribution of VPLS
3.3. BGP VPLS Operation . . . . . . . . . . . . . . . . . . . . 16 Information between ASBRs ..........................14
3.4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . 17 3.4.3. Method (c): Multi-Hop EBGP Redistribution
3.4.1. a) VPLS-to-VPLS connections at the ASBRs. . . . . . . 18 of VPLS Information ................................15
3.4.2. b) EBGP redistribution of VPLS information between 3.4.4. Allocation of VE IDs across Multiple ASes ..........16
ASBRs. . . . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Multi-homing and Path Selection ...........................16
3.4.3. c) Multi-hop EBGP redistribution of VPLS 3.6. Hierarchical BGP VPLS .....................................17
information between ASes. . . . . . . . . . . . . . . 20 4. Data Plane .....................................................18
3.4.4. Allocation of VE IDs Across Multiple ASes . . . . . . 20 4.1. Encapsulation .............................................18
3.5. Multi-homing and Path Selection . . . . . . . . . . . . . 21 4.2. Forwarding ................................................18
3.6. Hierarchical BGP VPLS . . . . . . . . . . . . . . . . . . 21 4.2.1. MAC Address Learning ...............................18
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.2. Aging ..............................................19
4.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 24 4.2.3. Flooding ...........................................19
4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.4. Broadcast and Multicast ............................20
4.2.1. MAC address learning . . . . . . . . . . . . . . . . . 24 4.2.5. "Split Horizon" Forwarding .........................20
4.2.2. Aging . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.6. Qualified and Unqualified Learning .................21
4.2.3. Flooding . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.7. Class of Service ...................................21
4.2.4. Broadcast and Multicast . . . . . . . . . . . . . . . 25 5. Deployment Options .............................................21
4.2.5. "Split Horizon" Forwarding . . . . . . . . . . . . . . 26 6. Security Considerations ........................................22
4.2.6. Qualified and Unqualified Learning . . . . . . . . . . 26 7. IANA Considerations ............................................23
4.2.7. Class of Service . . . . . . . . . . . . . . . . . . . 26 8. References .....................................................24
5. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References ......................................24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8.2. Informative References ....................................24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Contributors .........................................26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix B. Acknowledgements .....................................26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
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 an Ethernet LAN to customers of a Service Provider. respects as an Ethernet LAN to customers of a Service Provider.
However, in a VPLS, the customers are not all connected to a single However, in a VPLS, the customers are not all connected to a single
LAN; the customers may be spread across a metro or wide area. In LAN; the customers may be spread across a metro or wide area. In
essence, a VPLS glues together several individual LANs across a essence, a VPLS glues together several individual LANs across a
packet-switched network to appear and function as a single LAN ([9]). packet switched network to appear and function as a single LAN [9].
This is accomplished by incorporating MAC address learning, flooding This is accomplished by incorporating MAC address learning, flooding,
and forwarding functions in the context of pseudowires that connect and forwarding functions in the context of pseudowires that connect
these individual LANs across the packet-switched network. these individual LANs across the packet switched network.
This document details the functions needed to offer VPLS, and then This document details the functions needed to offer VPLS, and then
goes on to describe a mechanism for the autodiscovery of the goes on to describe a mechanism for the auto-discovery of the
endpoints of a VPLS as well as for signaling a VPLS. It also endpoints of a VPLS as well as for signaling a VPLS. It also
describes how VPLS frames are transported over tunnels across a describes how VPLS frames are transported over tunnels across a
packet switched network. The autodiscovery and signaling mechanism packet switched network. The auto-discovery and signaling mechanism
uses BGP as the control plane protocol. This document also briefly uses BGP as the control plane protocol. This document also briefly
discusses deployment options, in particular, the notion of decoupling discusses deployment options, in particular, the notion of decoupling
functions across devices. functions across devices.
Alternative approaches include: [14], which allows one to build a Alternative approaches include: [14], which allows one to build a
Layer 2 VPN with Ethernet as the interconnect; and [13]), which Layer 2 VPN with Ethernet as the interconnect; and [13], which allows
allows one to set up an Ethernet connection across a packet-switched 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
[10]. [10].
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
[4] to establish VPLS service, i.e., for the autodiscovery of VPLS [4] to establish VPLS service, i.e., for the auto-discovery 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 instance. Section 3 focuses on this, and constitute a given VPLS instance. Section 3 focuses on this, and
also describes how a VPLS that spans Autonomous System boundaries is also describes how a VPLS that spans Autonomous System boundaries is
set up, as well as how multi-homing is handled. Using BGP as the set up, as well as how multi-homing is handled. Using BGP as the
control plane for VPNs is not new (see [14], [6] and [11]): what is control plane for VPNs is not new (see [14], [6], and [11]): what is
described here is based on the mechanisms proposed in [6]. described here is based on the mechanisms proposed in [6].
The forwarding plane and the actions that a participating Provider The forwarding plane and the actions that a participating Provider
Edge (PE) router offering the VPLS service must take is described in Edge (PE) router offering the VPLS service must take is described in
Section 4. 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 1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 ([1]). document are to be interpreted as described in RFC 2119 [1].
1.3. Changes from version 06 to 07
[NOTE to RFC Editor: this section is to be removed before
publication.]
Note: the DISCUSSes below are referred to by id; they can be accessed
at https://datatracker.ietf.org/public/
pidtracker.cgi?command=view_comment&id=[ID]
Updated title of doc to reflect use of BGP. (Fenner's DISCUSS id
44901).
Addressed Russ Housley's DISCUSSes on Figure 6 and Section 6 (ids
44778 and 44779).
Addressed Sam Hartman's DISCUSS on the Security Considerations (id
48432).
Resolution of Kessens' DISCUSS (id 44870):
1. Reference to RFC 4364 has been made normative. There is no
normative text in ref draft-kompella-l2vpn-l2vpn -- any such text
has long since been incorporated directly into this document.
2. Description and IANA section updated.
3. Expanded section (b) of Section 3.4 to clarify the data plane
operation for option b.
4. Updated Section 3.5 to clarify that a VPLS customer can run STP
independent of whether the SP uses multi-homing or not.
5. P bit text deleted (left over from an earlier edit.)
6. Addressed (hopefully) by Sam's DISCUSS.
7. Updated Security Considerations to incorporate the techniques
described in RFC 4364 for inter-AS VPNs. Also, added a paragraph
stating that misconfiguration could cause inter-VPLS connections,
just as can happen with RFC 4364.
Updated references; added reference to RFC 4023.
1.4. Changes from version 05 to 06
[NOTE to RFC Editor: this section is to be removed before
publication.]
Changes in response to GenART review.
Updated Abstract and Introduction to make it clear that VPLS is an
Ethernet-based service.
Added sections on Aging, Broadcast and Multicast, Qualified and
Unqualified learning and CoS. Also added a section on scaling the
BGP control plane. These were requested for consistency between the
BGP and LDP VPLS documents.
Added a section clarifying the concepts of label blocks, why they are
necessary and how they are used.
For multi-AS operation, added a short introduction to the three
options, comparing their usage.
Lots of clean-up: consistent usage of terms, expansion of acronyms
before use, references.
1.5. Changes from version 04 to 05
[NOTE to RFC Editor: this section is to be removed before
publication.]
Updated IANA section to reflect agreement with authors of [11] that
the two docs should use the same AFI for L2VPN information.
Addressed comments received from Alex Zinin. No technical changes,
but a more complete description to cover the issues that Alex raised:
1. encoding of BGP NEXT_HOP for the new AFI/SAFI is not described
2. VE ID, Block offset, Block size, Label base are not described
anywhere
3. no information on how the receiving PE choose the PW label
4. section 3.2.2 talks about PE capabilities all of a sudden and
introduces a L2 Info Community, whose fields and use are not
described
Changes to address these:
1. Broke up section 3.2.1 into "Concepts" and "PW Setup".
2. Expanded section on "Signaling PE Capabilities".
3. Added a new section 3.3 "BGP VPLS Operation".
4. Minor tweaking, e.g. to fix section number references.
1.6. Changes from version 03 to 04
[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 the following figure. This will be described with reference to the following figure.
----- -----
/ A1 \ / A1 \
---- ____CE1 | ---- ____CE1 |
/ \ -------- -------- / | | / \ -------- -------- / | |
| A2 CE2- / \ / PE1 \ / | A2 CE2- / \ / PE1 \ /
skipping to change at page 8, line 39 skipping to change at page 5, line 13
Figure 1: Example of a VPLS Figure 1: Example of a VPLS
2.1. Terminology 2.1. Terminology
Terminology similar to that in [6] is used: a Service Provider (SP) Terminology similar to that in [6] is used: a Service Provider (SP)
network with P (Provider-only) and PE (Provider Edge) routers, and network with P (Provider-only) and PE (Provider Edge) routers, and
customers with CE (Customer Edge) devices. Here, however, there is customers with CE (Customer Edge) devices. Here, however, there is
an additional concept, that of a "u-PE", a Layer 2 PE device used for an additional concept, that of a "u-PE", a Layer 2 PE device used for
Layer 2 aggregation. The notion of u-PE is described further in Layer 2 aggregation. The notion of u-PE is described further in
Section 5. PE and u-PE devices are "VPLS-aware", which means that Section 5. PE and u-PE devices are "VPLS-aware", which means that
they know that a VPLS service is being offered. We will call these they know that a VPLS service is being offered. The term "VE" refers
VPLS edge devices, which could be either a PE or an u-PE, a VE. to a VPLS edge device, which could be either a PE or a u-PE.
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
switches are invisible, and hence will not be discussed further. switches are invisible, and hence will not be discussed further.
Furthermore, a u-PE may be connected to a PE via Layer 2 and Layer 3 Furthermore, a u-PE may be connected to a PE via Layer 2 and Layer 3
devices; this will be discussed further in a later section. devices; this will be discussed further in a later section.
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 the VPLS to which the packet belongs as well as the
the ingress PE. In this document, the demultiplexor is an MPLS 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) fully meshed with tunnels over which are assumed to be (logically) fully 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 Generic Routing
tunnels, established by RSVP-TE or LDP. These tunnels are Encapsulation (GRE), or MPLS tunnels, established by Resource
established independently of the services offered over them; the Reservation Protocol - Traffic Engineering (RSVP-TE) or LDP. These
signaling and establishment of these tunnels are not discussed in tunnels are established independently of the services offered over
this document. them; the signaling and establishment of these tunnels are not
discussed in 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 in All the PEs participating in a VPLS are assumed to be fully meshed in
the data plane, i.e., there is a bidirectional pseudowire between the data plane, i.e., there is a bidirectional pseudowire between
every pair of PEs participating in that VPLS, and thus every every pair of PEs participating in that VPLS, and thus every
(ingress) PE can send a VPLS packet to the egress PE(s) directly, (ingress) PE can send a VPLS packet to the egress PE(s) directly,
without the need for an intermediate PE (see Section 4.2.5.) This without the need for an intermediate PE (see Section 4.2.5.) This
requires that VPLS PEs are logically fully meshed in the control requires that VPLS PEs are logically fully meshed in the control
plane so that a PE can send a message to another PE to set up the plane so that a PE can send a message to another PE to set up the
necessary pseudowires. See Section 3.6 for a discussion on necessary pseudowires. See Section 3.6 for a discussion on
alternatives to achieve a logical full mesh in the control plane. alternatives to achieve a logical full mesh in the control plane.
2.3. Interactions 2.3. Interactions
VPLS is a "LAN Service" in that CE devices that belong to VPLS V can VPLS is a "LAN Service" in that CE devices that belong to a given
interact through the SP network as if they were connected by a LAN. VPLS instance V can interact through the SP network as if they were
VPLS is "private" in that CE devices that belong to different VPLSs connected by a LAN. VPLS is "private" in that CE devices that belong
cannot interact. VPLS is "virtual" in that multiple VPLSs can be to different VPLSs cannot interact. VPLS is "virtual" in that
offered over a common packet switched network. multiple VPLSs can be 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, 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. 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 PE devices can participate simultaneously in both VPLS and IP VPNs
([6]). These are independent services, and the information exchanged [6]. These are independent services, and the information exchanged
for each type of service is kept separate as the Network Layer for each type of service is kept separate as the Network Layer
Reachability Information (NLRI) used for this exchange have different Reachability Information (NLRI) used for this exchange has different
Address Family Identifiers (AFI) and Subsequent Address Family Address Family Identifiers (AFIs) and Subsequent Address Family
Identifiers (SAFI). Consequently, an implementation MUST maintain a Identifiers (SAFIs). Consequently, an implementation MUST maintain a
separate routing storage for each service. However, multiple separate routing storage for each service. However, multiple
services can use the same underlying tunnels; the VPLS or VPN label services can use the same underlying tunnels; the VPLS or VPN label
is used to demultiplex the packets belonging to different services. 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: auto-
autodiscovery, and setup and teardown of the pseudowires that discovery, and setup and teardown of the pseudowires that constitute
constitute the VPLS, often called signaling. Section 3.1 and the VPLS, often called signaling. Section 3.1 and Section 3.2
Section 3.2 describe these functions. Both of these functions are describe these functions. Both of these functions are accomplished
accomplished with a single BGP Update advertisement; Section 3.3 with a single BGP Update advertisement; Section 3.3 describes how
describes how this is done by detailing BGP protocol operation for this is done by detailing BGP protocol operation for VPLS.
VPLS. Section 3.4 describes the setting up of pseudowires that span Section 3.4 describes the setting up of pseudowires that span
Autonomous Systems. Section 3.5 describes how multi-homing is Autonomous Systems. Section 3.5 describes how multi-homing is
handled. handled.
3.1. Autodiscovery 3.1. Auto-Discovery
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 instance. A PE can either be configured participate in a given VPLS instance. A PE either can be configured
with the identities of all the other PEs in a given VPLS, or the PE with the identities of all the other PEs in a given VPLS or can use
can use some protocol to discover the other PEs. The latter is some protocol to discover the other PEs. The latter is called auto-
called autodiscovery. discovery.
The former approach is fairly configuration-intensive, especially The former approach is fairly configuration-intensive, especially
since it is required that the PEs participating in a given VPLS are since it is required that the PEs participating in a given VPLS are
fully meshed (i.e., that every PE in a given VPLS establish fully meshed (i.e., that every PE in a given VPLS establish
pseudowires to every other PE in that VPLS). Furthermore, when the pseudowires to every other PE in that VPLS). Furthermore, when the
topology of a VPLS changes (i.e., a PE is added to, or removed from topology of a VPLS changes (i.e., a PE is added to, or removed from,
the VPLS), the VPLS configuration on all PEs in that VPLS must be the VPLS), the VPLS configuration on all PEs in that VPLS must be
changed. changed.
In the autodiscovery approach, each PE "discovers" which other PEs In the auto-discovery 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 instance established on this PE, not the identity of of the VPLS instance established on this PE, not the identity of
every other PE in that VPLS instance -- that is auto-discovered. every other PE in that VPLS instance -- that is auto-discovered.
Moreover, when the topology of a VPLS changes, only the affected PE's Moreover, when the topology of a VPLS changes, only the affected PE's
configuration changes; other PEs automatically find out about the configuration changes; other PEs automatically find out about the
change and adapt. change and adapt.
3.1.1. Functions 3.1.1. Functions
A PE that participates in a given VPLS instance V must be able to A PE that participates in a given VPLS instance V must be able to
tell all other PEs in VPLS V that it is also a member of V. A PE must tell all other PEs in VPLS V that it is also a member of V. A PE
also have a means of declaring that it no longer participates in a must also have a means of declaring that it no longer participates in
VPLS. To do both of these, the PE must have a means of identifying a a VPLS. To do both of these, the PE must have a means of identifying
VPLS and a means by which to communicate to all other PEs. a VPLS 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 auto-discovery described here is based on
[14] and [6]; it uses BGP extended communities [5] to identify [14] and [6]; it uses BGP extended communities [5] to identify
members of a VPLS, in particular, the Route Target community, whose members of a VPLS, in particular, the Route Target community, whose
format is described in [5]. The semantics of the use of Route format is described in [5]. The semantics of the use of Route
Targets is described in [6]; their use in VPLS is identical. Targets is described in [6]; 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
skipping to change at page 13, line 13 skipping to change at page 8, line 50
involved in distributing this Update to other PEs. involved in distributing this Update to other PEs.
3.2.1. Label Blocks 3.2.1. Label Blocks
To accomplish this, we introduce the notion of "label blocks". A To accomplish this, we introduce the notion of "label blocks". A
label block, defined by a label base LB and a VE block size VBS, is a label block, defined by a label base LB and a VE block size VBS, is a
contiguous set of labels {LB, LB+1, ..., LB+VBS-1}. Here's how label contiguous set of labels {LB, LB+1, ..., LB+VBS-1}. Here's how label
blocks work. All PEs within a given VPLS are assigned unique VE IDs blocks work. All PEs within a given VPLS are assigned unique VE IDs
as part of their configuration. A PE X wishing to send a VPLS update as part of their configuration. A PE X wishing to send a VPLS update
sends the same label block information to all other PEs. Each sends the same label block information to all other PEs. Each
receiving PE infers the label intended for PE X by adding their receiving PE infers the label intended for PE X by adding its
(unique) VE ID to the label base. In this manner, each receiving PE (unique) VE ID to the label base. In this manner, each receiving PE
gets a unique demultiplexor for PE X for that VPLS. gets a unique demultiplexor for PE X for that VPLS.
This simple notion is enhanced with the concept of a VE block offset This simple notion is enhanced with the concept of a VE block offset
VBO. A label block defined by <LB, VBO, VBS> is the set {LB+VBO, LB+ VBO. A label block defined by <LB, VBO, VBS> is the set {LB+VBO,
VBO+1, ..., LB+VBO+VBS-1}. Thus, instead of a single large label LB+VBO+1, ..., LB+VBO+VBS-1}. Thus, instead of a single large label
block to cover all VE IDs in a VPLS, one can have several label block to cover all VE IDs in a VPLS, one can have several label
blocks, each with a different label base. This makes label block blocks, each with a different label base. This makes label block
management easier, and also allows PE X to cater gracefully to a PE management easier, and also allows PE X to cater gracefully to a PE
joining a VPLS with a VE ID that is not covered by the set of label joining a VPLS with a VE ID that is not covered by the set of label
blocks that that PE X has already advertised. blocks that PE X has already advertised.
When a PE starts up, or is configured with a new VPLS instance, the When a PE starts up, or is configured with a new VPLS instance, the
BGP process may wish to wait to receive several advertisements for BGP process may wish to wait to receive several advertisements for
that VPLS instance from other PEs to improve the efficiency of label that VPLS instance from other PEs to improve the efficiency of label
block allocation. block allocation.
3.2.2. VPLS BGP NLRI 3.2.2. VPLS BGP NLRI
The VPLS BGP NLRI described below, with a new AFI and SAFI (see [4]) The VPLS BGP NLRI described below, with a new AFI and SAFI (see [4])
is used to exchange VPLS membership and demultiplexors. is used to exchange VPLS membership and demultiplexors.
A VPLS BGP NLRI has the following information elements: a VE ID, a VE A VPLS BGP NLRI has the following information elements: a VE ID, a VE
Block Offset, a VE Block Size and a label base. The format of the Block Offset, a VE Block Size, and a label base. The format of the
VPLS NLRI is given below. The AFI is the L2VPN AFI (to be assigned VPLS NLRI is given below. The AFI is the L2VPN AFI (25), and the
by IANA), and the SAFI is the VPLS SAFI (65). The Length field is in SAFI is the VPLS SAFI (65). The Length field is in octets.
octets.
+------------------------------------+ +------------------------------------+
| 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) |
+------------------------------------+ +------------------------------------+
skipping to change at page 14, line 27 skipping to change at page 9, line 51
+------------------------------------+ +------------------------------------+
Figure 2: BGP NLRI for VPLS Information Figure 2: BGP NLRI for VPLS Information
A PE participating in a VPLS must have at least one VE ID. If the PE A PE participating in a VPLS must have at least one VE ID. If the PE
is the VE, it typically has one VE ID. If the PE is connected to is the VE, it typically has one VE ID. If the PE is connected to
several u-PEs, it has a distinct VE ID for each u-PE. It may several u-PEs, it has a distinct VE ID for each u-PE. It may
additionally have a VE ID for itself, if it itself acts as a VE for additionally have a VE ID for itself, if it itself acts as a VE for
that VPLS. In what follows, we will call the PE announcing the VPLS that VPLS. In what follows, we will call the PE announcing the VPLS
NLRI PE-a, and we will assume that PE-a owns VE ID V (either NLRI PE-a, and we will assume that PE-a owns VE ID V (either
belonging to PE-a itself, or to a u-PE connected to PE-a). belonging to PE-a itself or to a u-PE connected to PE-a).
VE IDs are typically assigned by the network administrator. Their VE IDs are typically assigned by the network administrator. Their
scope is local to a VPLS. A given VE ID should belong to only one scope is local to a VPLS. A given VE ID should belong to only one
PE, unless a CE is multi-homed (see Section 3.5). PE, unless a CE is multi-homed (see Section 3.5).
A label block is a set of demultiplexor labels used to reach a given A label block is a set of demultiplexor labels used to reach a given
VE ID. A VPLS BGP NLRI with VE ID V, VE Block Offset VBO, VE Block VE ID. A VPLS BGP NLRI with VE ID V, VE Block Offset VBO, VE Block
Size VBS and label base LB communicates to its peers the following: Size VBS, and label base LB communicates to its peers the following:
label block for V: labels from LB to (LB + VBS - 1), and label block for V: labels from LB to (LB + VBS - 1), and
remote VE set for V: from VBO to (VBO + VBS - 1). remote VE set for V: from VBO to (VBO + VBS - 1).
There is a one-to-one correspondence between the remote VE set and There is a one-to-one correspondence between the remote VE set and
the label block: VE ID (VBO + n) corresponds to label (LB + n). the label block: VE ID (VBO + n) corresponds to label (LB + n).
3.2.3. PW Setup and Teardown 3.2.3. PW Setup and Teardown
Suppose PE-a is part of VPLS foo, and makes an announcement with VE Suppose PE-a is part of VPLS foo and makes an announcement with VE ID
ID V, VE Block Offset VBO, VE Block Size VBS and label base LB. If V, VE Block Offset VBO, VE Block Size VBS, and label base LB. If
PE-b is also part of VPLS foo, and has VE ID W, PE-b does the PE-b is also part of VPLS foo and has VE ID W, PE-b does the
following: following:
1. checks if W is part of PE-a's 'remote VE set': if VBO <= W < VBO 1. checks if W is part of PE-a's 'remote VE set': if VBO <= W < VBO
+ VBS, then W is part of PE-a's remote VE set. If not, PE-b + VBS, then W is part of PE-a's remote VE set. If not, PE-b
ignores this message, and skips the rest of this procedure. ignores this message, and skips the rest of this procedure.
2. sets up a PW to PE-a: the demultiplexor label to send traffic 2. sets up a PW to PE-a: the demultiplexor label to send traffic
from PE-b to PE-a is computed as (LB + W - VBO). from PE-b to PE-a is computed as (LB + W - VBO).
3. checks if V is part of any 'remote VE set' that PE-b announced, 3. checks if V is part of any 'remote VE set' that PE-b announced,
i.e., PE-b checks if V belongs to some remote VE set that PE-b i.e., PE-b checks if V belongs to some remote VE set that PE-b
announced, say with VE Block Offset VBO', VE Block Size VBS' and announced, say with VE Block Offset VBO', VE Block Size VBS', and
label base LB'. If not, PE-b MUST make a new announcement as label base LB'. If not, PE-b MUST make a new announcement as
described in Section 3.3. described in Section 3.3.
4. sets up a PW from PE-a: the demultiplexor label over which PE-b 4. sets up a PW from PE-a: the demultiplexor label over which PE-b
should expect traffic from PE-a is computed as: (LB' + V - VBO'). should expect traffic from PE-a is computed as: (LB' + V - VBO').
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 pseudowire between X and Y. its ends of the pseudowire between X and Y.
3.2.4. Signaling PE Capabilities 3.2.4. Signaling PE Capabilities
The following extended attribute, the "Layer2 Info Extended The following extended attribute, the "Layer2 Info Extended
Community", is used to signal control information about the Community", is used to signal control information about the
pseudowires to be setup for a given VPLS. The extended community pseudowires to be setup for a given VPLS. The extended community
value is to be allocated by IANA (currently used value is 0x800A). value is to be allocated by IANA (currently used value is 0x800A).
This information includes the Encaps Type (type of encapsulation on This information includes the Encaps Type (type of encapsulation on
the pseudowires), Control Flags (control information regarding the the pseudowires), Control Flags (control information regarding the
pseudowires) and the Maximum Transmission Unit (MTU) to be used on pseudowires), and the Maximum Transmission Unit (MTU) to be used on
the pseudowires. the pseudowires.
The Encaps Type for VPLS is 19. The Encaps Type for VPLS is 19.
+------------------------------------+ +------------------------------------+
| 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) |
skipping to change at page 16, line 16 skipping to change at page 11, line 36
| MBZ |C|S| (MBZ = MUST Be Zero) | MBZ |C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 4: Control Flags Bit Vector Figure 4: Control Flags Bit Vector
With reference to Figure 4, the following bits in the Control Flags With reference to Figure 4, the following bits in the Control Flags
are defined; the remaining bits, designated MBZ, MUST be set to zero are defined; the remaining bits, designated MBZ, MUST be set to zero
when sending and MUST be ignored when receiving this community. when sending and MUST be ignored when receiving this community.
Name Meaning Name Meaning
C A Control word (
[7] C A Control word [7] MUST or MUST NOT be present when
) MUST or MUST NOT be present when
sending VPLS packets to this PE, depending on whether C sending VPLS packets to this PE, depending on whether C
is 1 or 0, respectively is 1 or 0, respectively
S Sequenced delivery of frames MUST or MUST NOT be used S Sequenced delivery of frames MUST or MUST NOT be used
when sending VPLS packets to this PE. depending on when sending VPLS packets to this PE, depending on
whether S is 1 or 0, respectively whether S is 1 or 0, respectively
3.3. BGP VPLS Operation 3.3. BGP VPLS Operation
To create a new VPLS, say VPLS foo, a network administrator must pick To create a new VPLS, say VPLS foo, a network administrator must pick
a RT for VPLS foo, say RT-foo. This will be used by all PEs that an RT for VPLS foo, say RT-foo. This will be used by all PEs that
serve VPLS foo. To configure a given PE, say PE-a, to be part of serve VPLS foo. To configure a given PE, say PE-a, to be part of
VPLS foo, the network administrator only has to choose a VE ID V for VPLS foo, the network administrator only has to choose a VE ID V for
PE-a. (If PE-a is connected to u-PEs, PE-a may be configured with PE-a. (If PE-a is connected to u-PEs, PE-a may be configured with
more than one VE ID; in that case, the following is done for each VE more than one VE ID; in that case, the following is done for each VE
ID). The PE may also be configured with a Route Distinguisher (RD); ID). The PE may also be configured with a Route Distinguisher (RD);
if not, it generates a unique RD for VPLS foo. Say the RD is if not, it generates a unique RD for VPLS foo. Say the RD is
RD-foo-a. PE-a then generates an initial label block and a remote VE RD-foo-a. PE-a then generates an initial label block and a remote VE
set for V, defined by VE Block Offset VBO, VE Block Size VBS and set for V, defined by VE Block Offset VBO, VE Block Size VBS, and
label base LB. These may be empty. label base LB. These may be empty.
PE-a then creates a VPLS BGP NLRI with RD RD-foo-a, VE ID V, VE Block PE-a then creates a VPLS BGP NLRI with RD RD-foo-a, VE ID V, VE Block
Offset VBO, VE Block Size VBS and label base LB. To this, it Offset VBO, VE Block Size VBS and label base LB. To this, it
attaches a Layer2 Info Extended Community and a RT, RT-foo. It sets attaches a Layer2 Info Extended Community and an RT, RT-foo. It sets
the BGP Next Hop for this NLRI as itself, and announces this NLRI to the BGP Next Hop for this NLRI as itself, and announces this NLRI to
its peers. The Network Layer protocol associated with the Network its peers. The Network Layer protocol associated with the Network
Address of the Next Hop for the combination <AFI=L2VPN AFI, SAFI=VPLS Address of the Next Hop for the combination <AFI=L2VPN AFI, SAFI=VPLS
SAFI> is IP; this association is required by [4], Section 5. If the SAFI> is IP; this association is required by [4], Section 5. If the
value of the Length of the Next Hop field is 4, then the Next Hop value of the Length of the Next Hop field is 4, then the Next Hop
contains an IPv4 address. If this value is 16, then the Next Hop contains an IPv4 address. If this value is 16, then the Next Hop
contains an IPv6 address. contains an IPv6 address.
If PE-a hears from another PE, say PE-b, a VPLS BGP announcement with If PE-a hears from another PE, say PE-b, a VPLS BGP announcement with
RT-foo and VE ID W, then PE-a knows that PE-b is a member of the same RT-foo and VE ID W, then PE-a knows that PE-b is a member of the same
VPLS (autodiscovery). PE-a then has to set up its part of a VPLS VPLS (auto-discovery). PE-a then has to set up its part of a VPLS
pseudowire between PE-a and PE-b, using the mechanisms in pseudowire between PE-a and PE-b, using the mechanisms in
Section 3.2. Similarly, PE-b will have discovered that PE-a is in Section 3.2. Similarly, PE-b will have discovered that PE-a is in
the same VPLS, and PE-b must set up its part of the VPLS pseudowire. the same VPLS, and PE-b must set up its part of the VPLS pseudowire.
Thus, signaling and pseudowire setup is also achieved with the same Thus, signaling and pseudowire setup is also achieved with the same
Update message. Update message.
If W is not in any remote VE set that PE-a announced for VE ID V in If W is not in any remote VE set that PE-a announced for VE ID V in
VPLS foo, PE-b will not be able to set up its part of the pseudowire VPLS foo, PE-b will not be able to set up its part of the pseudowire
to PE-a. To address this, PE-a can choose to withdraw the old to PE-a. To address this, PE-a can choose to withdraw the old
announcement(s) it made for VPLS foo, and announce a new Update with announcement(s) it made for VPLS foo, and announce a new Update with
a larger remote VE set and corresponding label block that covers all a larger remote VE set and corresponding label block that covers all
VE IDs that are in VPLS foo. This however, may cause some service VE IDs that are in VPLS foo. This, however, may cause some service
disruption. An alternative for PE-a is to create a new remote VE set disruption. An alternative for PE-a is to create a new remote VE set
and corresponding label block, and announce them in a new Update, and corresponding label block, and announce them in a new Update,
without withdrawing previous announcements. without withdrawing previous announcements.
If PE-a's configuration is changed to remove VE ID V from VPLS foo, If PE-a's configuration is changed to remove VE ID V from VPLS foo,
then PE-a MUST withdraw all its announcements for VPLS foo that then PE-a MUST withdraw all its announcements for VPLS foo that
contain VE ID V. If all of PE-a's links to its CEs in VPLS foo go contain VE ID V. If all of PE-a's links to its CEs in VPLS foo go
down, then PE-a SHOULD either withdraw all its NLRIs for VPLS foo, or down, then PE-a SHOULD either withdraw all its NLRIs for VPLS foo or
let other PEs in the VPLS foo know in some way that PE-a is no longer let other PEs in the VPLS foo know in some way that PE-a is no longer
connected to its CEs. connected to its CEs.
3.4. Multi-AS VPLS 3.4. Multi-AS VPLS
As in [14] and [6], the above autodiscovery and signaling functions As in [14] and [6], the above auto-discovery 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 is needed; between those PEs, so some means of signaling across ASes is needed;
and 2) there may not be PE-to-PE tunnels between the ASes. and 2) there may not be PE-to-PE tunnels between the ASes.
A similar problem is solved in [6], Section 10. Three methods are A similar problem is solved in [6], 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
skipping to change at page 18, line 18 skipping to change at page 13, line 33
/ \ / \ / \ / \ / \ / \ / \ / \
\___/ AS 1 \ / AS 2 \___/ \___/ AS 1 \ / AS 2 \___/
\ / \ /
+-----+ +-------+ | +-------+ +-----+ +-----+ +-------+ | +-------+ +-----+
| PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 | | PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 |
+-----+ +-------+ | +-------+ +-----+ +-----+ +-------+ | +-------+ +-----+
___ / \ ___ ___ / \ ___
/ \ / \ / \ / \ / \ / \
\__________/ \____________/ \____________/ \__________/ \__________/ \____________/ \____________/ \__________/
Figure 6: Inter-AS VPLS Figure 5: Inter-AS VPLS
As in the above reference, three methods for signaling inter-provider As in the above reference, three methods for signaling inter-provider
VPLS are given; these are presented in order of increasing VPLS are given; these are presented in order of increasing
scalability. Method (a) is the easiest to understand conceptually, scalability. Method (a) is the easiest to understand conceptually,
and the easiest to deploy; however, it requires an Ethernet and the easiest to deploy; however, it requires an Ethernet
interconnect between the ASes, and both VPLS control and data plane interconnect between the ASes, and both VPLS control and data plane
state on the AS border routers (ASBRs). Method (b) requires VPLS state on the AS border routers (ASBRs). Method (b) requires VPLS
control plane state on the ASBRs and MPLS on the AS-AS interconnect control plane state on the ASBRs and MPLS on the AS-AS interconnect
(which need not be Ethernet). Method (c) requires MPLS on the AS-AS (which need not be Ethernet). Method (c) requires MPLS on the AS-AS
interconnect, but no VPLS state of any kind on the ASBRs. interconnect, but no VPLS state of any kind on the ASBRs.
3.4.1. a) VPLS-to-VPLS connections at the ASBRs. 3.4.1. Method (a): VPLS-to-VPLS Connections at the ASBRs
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 ASBR1 AS2 here. The ASBR on the neighboring AS (ASBR2) is viewed by ASBR1
as a CE for the VPLSs that span AS1 and AS2; similarly, ASBR2 acts as as a CE for the VPLSs that span AS1 and AS2; similarly, ASBR2 acts as
a PE for this VPLS from AS2's point of view, and views ASBR1 as a CE. a PE for this VPLS from AS2's point of view, and views ASBR1 as a CE.
This method does not require MPLS on the ASBR1-ASBR2 link, but does This method does not require MPLS on the ASBR1-ASBR2 link, but does
require that this link carry Ethernet traffic, and that there be a require that this link carry Ethernet traffic and that there be a
separate VLAN sub-interface for each VPLS traversing this link. It separate VLAN sub-interface for each VPLS traversing this link. It
further requires that ASBR1 does the PE operations (discovery, further requires that ASBR1 does the PE operations (discovery,
signaling, MAC address learning, flooding, encapsulation, etc.) for signaling, MAC address learning, flooding, encapsulation, etc.) for
all VPLSs that traverse ASBR1. This imposes a significant burden on all VPLSs that traverse ASBR1. This imposes a significant burden on
ASBR1, both on the control plane and the data plane, which limits the ASBR1, both on the control plane 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 (STP) ([15]), or some other means of loop detection and Protocol (STP) [15], or some other means of loop detection and
prevention, must be run on each VPLS that spans these ASes, so that a prevention, must be run on each VPLS that spans these ASes, so that a
loop-free topology can be constructed in each VPLS. This imposes a loop-free topology can be constructed in each VPLS. This imposes a
further burden on the ASBRs and PEs participating in those VPLSs, as further burden on the ASBRs and PEs participating in those VPLSs, as
these devices would need to run a loop detection algorithm for each these devices would need to run a loop detection algorithm for each
such VPLS. How this may be achieved is outside the scope of this such VPLS. How this may be achieved is outside the scope of this
document. document.
3.4.2. b) EBGP redistribution of VPLS information between ASBRs. 3.4.2. Method (b): EBGP Redistribution of VPLS Information between
ASBRs
This method requires I-BGP peerings between the PEs in AS1 and ASBR1 This method requires I-BGP peerings between the PEs in AS1 and ASBR1
in AS1 (perhaps via route reflectors), an E-BGP peering between ASBR1 in AS1 (perhaps via route reflectors), an E-BGP peering between ASBR1
and ASBR2 in AS2, and I-BGP peerings between ASBR2 and the PEs in and ASBR2 in AS2, and I-BGP peerings between ASBR2 and the PEs in
AS2. In the above example, PE1 sends a VPLS NLRI to ASBR1 with a AS2. In the above example, PE1 sends a VPLS NLRI to ASBR1 with a
label block and itself as the BGP nexthop; ASBR1 sends the NLRI to label block and itself as the BGP nexthop; ASBR1 sends the NLRI to
ASBR2 with new labels and itself as the BGP nexthop; and ASBR2 sends ASBR2 with new labels and itself as the BGP nexthop; and ASBR2 sends
the NLRI to PE2 with new labels and itself as the nexthop. the NLRI to PE2 with new labels and itself as the nexthop.
Correspondingly, there are three tunnels: T1 from PE1 to ASBR1, T2 Correspondingly, there are three tunnels: T1 from PE1 to ASBR1, T2
from ASBR1 to ASBR2, and T3 from ASBR2 to PE2. Within each tunnel, from ASBR1 to ASBR2, and T3 from ASBR2 to PE2. Within each tunnel,
the VPLS label to be used is determined by the receiving device; the VPLS label to be used is determined by the receiving device;
e.g., the VPLS label within T1 is a label from the label block that e.g., the VPLS label within T1 is a label from the label block that
ASBR1 sent to PE1. The ASBRs are responsible for receiving VPLS ASBR1 sent to PE1. The ASBRs are responsible for receiving VPLS
packets encapsulated in a tunnel, and performing the appropriate packets encapsulated in a tunnel and performing the appropriate label
label swap operations described next so that the next receiving swap operations described next so that the next receiving device can
device can correctly identify and forward the packet. correctly identify and forward the packet.
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 ASBR1, sends to PE2) is identical to the VPLS NLRI that PE1 sends to ASBR1,
except for the label block. To be precise, the Length, the Route except for the label block. To be precise, the Length, the Route
Distinguisher, the VE ID, the VE Block Offset, and the VE Block Size Distinguisher, the VE ID, the VE Block Offset, and the VE Block Size
MUST be the same; the Label Base may be different. Furthermore, MUST be the same; the Label Base may be different. Furthermore,
ASBR1 must also update its forwarding path as follows: if the Label ASBR1 must also update its forwarding path as follows: if the Label
Base sent by PE1 is L1, the Label-block Size is N, the Label Base Base sent by PE1 is L1, the Label-block Size is N, the Label Base
sent by ASBR1 is L2, and the tunnel label from ASBR1 to PE1 is T, sent by ASBR1 is L2, and the tunnel label from ASBR1 to PE1 is T,
then ASBR1 must install the following in the forwarding path: then ASBR1 must install the following in the forwarding path:
skipping to change at page 20, line 6 skipping to change at page 15, line 23
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 uses a get the right VPLS label from ASBR2's label block for PE1, and uses a
tunnel label to reach ASBR2. ASBR2 swaps the VPLS label with the tunnel label to reach ASBR2. ASBR2 swaps the VPLS label with the
label from ASBR1; ASBR1 then swaps the VPLS label with the label from label from ASBR1; ASBR1 then swaps the VPLS label with 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 are much simpler
than in method (a), being limited to label operations. Finally, the than in method (a), being limited to label operations. Finally, 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 need decisions, viz. BGP path and nexthop selection, so there is no need
to run the Spanning Tree Protocol on a per-VPLS basis. Thus, this to run the Spanning Tree Protocol on a per-VPLS basis. Thus, this
method is considerably more scalable than method (a). method is considerably more scalable than method (a).
3.4.3. c) Multi-hop EBGP redistribution of VPLS information between 3.4.3. Method (c): Multi-Hop EBGP Redistribution of VPLS Information
ASes. 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 not self to PE2; if this is via route reflectors, the BGP nexthop is not
changed. This requires that there be a tunnel LSP from PE1 to PE2. changed. This requires that there be a tunnel LSP from PE1 to PE2.
This tunnel LSP can be created exactly as in [6], section 10 (c), for This tunnel LSP can be created exactly as in [6], Section 10 (c), for
example using E-BGP to exchange labeled IPv4 routes for the PE example using E-BGP to exchange labeled IPv4 routes for the PE
loopbacks. loopbacks.
When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS label When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS label
corresponding to its own VE ID onto the packet. It then pushes the corresponding to its own VE ID onto the packet. It then 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 PE-to-PE the data plane) on the ASBRs. The ASBRs only need to set up PE-to-PE
tunnel LSPs in the control plane, and do label operations in the data tunnel LSPs in the control plane, and do label operations in the data
plane. Again, as in the case of method (b), the construction of plane. Again, as in the case of method (b), the construction of
loop-free VPLS topologies is done by routing decisions, i.e., BGP loop-free VPLS topologies is done by routing decisions, i.e., BGP
path and nexthop selection, so there is no need to run the Spanning path and nexthop selection, so there is no need to run the Spanning
Tree Protocol on a per-VPLS basis. This option is likely to be the Tree Protocol on a per-VPLS basis. This option is likely to be the
most scalable of the three methods presented here. most scalable of the three methods presented here.
3.4.4. Allocation of VE IDs Across Multiple ASes 3.4.4. Allocation of VE IDs across Multiple ASes
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 be no range can be allocated to AS1. The only caveat is that there be 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.5. Multi-homing and Path Selection 3.5. 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 be configured either 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. How this can be accomplished is outside the loop-free VPLS topology. How this can be accomplished is outside the
scope of this document; however, the rest of this section will scope of this document; however, the rest of this section will
describe in some detail the former case. Note that multi-homing by describe in some detail the former case. Note that multi-homing by
the SP and STP on the CEs can co-exist; thus it is recommended that the SP and STP on the CEs can co-exist; thus, it is recommended that
the VPLS customer run STP if the CEs are able to. the VPLS customer run STP if the CEs are able to.
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
are the same. If two PEs are assigned the same VE ID in a given Offset are the same. If two PEs are assigned the same VE ID in a
VPLS, they MUST use the same Route Distinguisher, and they SHOULD given VPLS, they MUST use the same Route Distinguisher, and they
announce the same VE Block Size for a given VE Offset. SHOULD announce the same VE Block Size for a given VE Offset.
3.6. Hierarchical BGP VPLS 3.6. Hierarchical BGP VPLS
This section discusses how one can scale the VPLS control plane when This section discusses how one can scale the VPLS control plane when
using BGP. There are at least three aspects of scaling the control using BGP. There are at least three aspects of scaling the control
plane: plane:
1. alleviating the full mesh connectivity requirement among VPLS BGP 1. alleviating the full mesh connectivity requirement among VPLS BGP
speakers; speakers;
2. limiting BGP VPLS message passing to just the interested speakers 2. limiting BGP VPLS message passing to just the interested speakers
rather than all BGP speakers; and rather than all BGP speakers; and
3. simplifying the addition and deletion of BGP speakers, whether 3. simplifying the addition and deletion of BGP speakers, whether
for VPLS or other applications. for VPLS or other applications.
Fortunately, the use of BGP for Internet routing as well as for IP Fortunately, the use of BGP for Internet routing as well as for IP
VPNs has yielded several good solutions for all these problems. The VPNs has yielded several good solutions for all these problems. The
basic technique is hierarchy, using BGP Route Reflectors (RRs) ([8]). basic technique is hierarchy, using BGP Route Reflectors (RRs) [8].
The idea is to designate a small set of Route Reflectors that are
The idea is to designate a small set of Route Reflectors which are
themselves fully meshed, and then establish a BGP session between themselves fully meshed, and then establish a BGP session between
each BGP speaker and one or more RRs. In this way, there is no need each BGP speaker and one or more RRs. In this way, there is no need
of direct full mesh connectivity among all the BGP speakers. If the for direct full mesh connectivity among all the BGP speakers. If the
particular scaling needs of a provider requires a large number of particular scaling needs of a provider require a large number of RRs,
RRs, then this technique can be applied recursively: the full mesh then this technique can be applied recursively: the full mesh
connectivity among the RRs can be brokered by yet another level of connectivity among the RRs can be brokered by yet another level of
RRs. The use of RRs solves problems 1 and 3 above. RRs. The use of RRs solves problems 1 and 3 above.
It is important to note that RRs, as used for VPLS and VPNs, are It is important to note that RRs, as used for VPLS and VPNs, are
purely a control plane technique. The use of RRs introduces no data purely a control plane technique. The use of RRs introduces no data
plane state and no data plane forwarding requirements on the RRs, and plane state and no data plane forwarding requirements on the RRs, and
does not in any way change the forwarding path of VPLS traffic. This does not in any way change the forwarding path of VPLS traffic. This
is in contrast to the technique of Hierarchical VPLS defined in [10]. is in contrast to the technique of Hierarchical VPLS defined in [10].
Another consequence of this approach is that it is not required that Another consequence of this approach is that it is not required that
one set of RRs handles all BGP messages, or that a particular RR one set of RRs handles all BGP messages, or that a particular RR
handle all messages from a given PE. One can define several sets of handle all messages from a given PE. One can define several sets of
RRs, for example a set to handle VPLS, another to handle IP VPNs and RRs, for example, a set to handle VPLS, another to handle IP VPNs,
another for Internet routing. Another partitioning could be to have and another for Internet routing. Another partitioning could be to
some subset of VPLSs and IP VPNs handled by one set of RRs, and have some subset of VPLSs and IP VPNs handled by one set of RRs, and
another subset of VPLSs and IP VPNs handled by another set of RRs; another subset of VPLSs and IP VPNs handled by another set of RRs;
the use of Route Target Filtering (RTF), described in [12] can make the use of Route Target Filtering (RTF), described in [12], can make
this simpler and more effective. this simpler and more effective.
Finally, problem 2 (that of limiting BGP VPLS message passing to just Finally, problem 2 (that of limiting BGP VPLS message passing to just
the interested BGP speakers) is addressed by the use of RTF. This the interested BGP speakers) is addressed by the use of RTF. This
technique is orthogonal to the use of RRs, but works well in technique is orthogonal to the use of RRs, but works well in
conjunction with RRs. RTF is also very effective in inter-AS VPLS; conjunction with RRs. RTF is also very effective in inter-AS VPLS;
more details on how RTF works and its benefits are provided in [12]. more details on how RTF works and its benefits are provided in [12].
It is worth mentioning an aspect of the control plane that is often a It is worth mentioning an aspect of the control plane that is often a
source of confusion. No MAC addresses are exchanged via BGP. All source of confusion. No MAC addresses are exchanged via BGP. All
MAC address learning and aging is done in the data plane individually MAC address learning and aging is done in the data plane individually
by each PE. The only task of BGP VPLS message exchange is by each PE. The only task of BGP VPLS message exchange is auto-
autodiscovery and label exchange. discovery and label exchange.
Thus, BGP processing for VPLS occurs when Thus, BGP processing for VPLS occurs when
1. a PE joins or leaves a VPLS; or 1. a PE joins or leaves a VPLS; or
2. a failure occurs in the network, bringing down a PE-PE tunnel or 2. a failure occurs in the network, bringing down a PE-PE tunnel or
a PE-CE link. a PE-CE link.
These events are relatively rare, and typically, each such event These events are relatively rare, and typically, each such event
causes one BGP update to be generated. Coupled with BGP's messaging causes one BGP update to be generated. Coupled with BGP's messaging
efficiency when used for signaling VPLS, these observations lead to efficiency when used for signaling VPLS, these observations lead to
the conclusion that BGP as a control plane for VPLS will scale quite the conclusion that BGP as a control plane for VPLS will scale quite
well both in terms of processing and memory requirements. well in terms of both processing and memory requirements.
4. Data Plane 4. Data Plane
This section discusses two aspects of the data plane for PEs and This section discusses two aspects of the data plane for PEs and
u-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.
skipping to change at page 24, line 25 skipping to change at page 18, line 44
4.2. Forwarding 4.2. Forwarding
VPLS packets are classified as belonging to a given service instance VPLS packets are classified as belonging to a given service instance
and associated forwarding table based on the interface over which the and associated forwarding table based on the interface over which the
packet is received. Packets are forwarded in the context of the packet is received. Packets are forwarded in the context of the
service instance based on the destination MAC address. The former service instance based on the destination MAC address. The former
mapping is determined by configuration. The latter is the focus of mapping is determined by configuration. The latter is the focus of
this section. 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 customer ports as well as the pseudowires on the SP "bridge" are the customer ports as well as the pseudowires on
a VE. Just as a learning bridge learns MAC addresses on its ports, a VE. Just as a learning bridge learns MAC addresses on its ports,
the SP bridge must learn MAC addresses at its VEs. 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 bridge source MAC address S on (logical) port P. If subsequently, the
receives a packet with destination MAC address S, it knows that it bridge receives a packet with destination MAC address S, it knows
should send the packet out on port P. that it should send the packet out on port P.
If a VE learns a source MAC address S on logical port P, then later If a VE learns a source MAC address S on logical port P, then later
sees S on a different port P', then the VE MUST update its FIB to sees S on a different port P', then the VE MUST update its FIB to
reflect the new port P'. A VE MAY implement a mechanism to damp reflect the new port P'. A VE MAY implement a mechanism to damp
flapping of source ports for a given MAC address. flapping of source ports for a given MAC address.
4.2.2. Aging 4.2.2. Aging
VPLS PEs SHOULD have an aging mechanism to remove a MAC address VPLS PEs SHOULD have an aging mechanism to remove a MAC address
associated with a logical port, much the same as learning bridges do. associated with a logical port, much the same as learning bridges do.
This is required so that a MAC address can be relearned if it "moves" This is required so that a MAC address can be relearned if it "moves"
from a logical port to another logical port, either because the from a logical port to another logical port, either because the
station to which that MAC address belongs really has moved, or station to which that MAC address belongs really has moved or because
because of a topology change in the LAN that causes this MAC address of a topology change in the LAN that causes this MAC address to
to arrive on a new port. In addition, aging reduces the size of a arrive on a new port. In addition, aging reduces the size of a VPLS
VPLS MAC table to just the active MAC addresses, rather than all MAC MAC table to just the active MAC addresses, rather than all MAC
addresses in that VPLS. addresses in that VPLS.
The "age" of a source MAC address S on a logical port P is the time The "age" of a source MAC address S on a logical port P is the time
since it was last seen as a source MAC on port P. If the age exceeds since it was last seen as a source MAC on port P. If the age exceeds
the aging time T, S MUST be flushed from the FIB. This of course the aging time T, S MUST be flushed from the FIB. This of course
means that every time S is seen as a source MAC address on port P, means that every time S is seen as a source MAC address on port P,
S's age is reset. S's age is reset.
An implementation SHOULD provide a configurable knob to set the aging An implementation SHOULD provide a configurable knob to set the aging
time T on a per-VPLS basis. In addition, an implementation MAY time T on a per-VPLS basis. In addition, an implementation MAY
skipping to change at page 25, line 37 skipping to change at page 20, line 9
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
responsible for further flooding the frame to CE1 and CE5 (unless PE1 responsible for further flooding the frame to CE1 and CE5 (unless PE1
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
u-PEs, it would announce that it has two u-PEs. PE3 could either two 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.4. Broadcast and Multicast 4.2.4. Broadcast and Multicast
There is a well-known broadcast MAC address. An Ethernet frame whose There is a well-known broadcast MAC address. An Ethernet frame whose
destination MAC address is the broadcast MAC address must be sent to destination MAC address is the broadcast MAC address must be sent to
all stations in that VPLS. This can be accomplished by the same all stations in that VPLS. This can be accomplished by the same
skipping to change at page 26, line 22 skipping to change at page 20, line 41
4.2.5. "Split Horizon" Forwarding 4.2.5. "Split Horizon" Forwarding
When a PE capable of flooding (say PEx) receives a broadcast Ethernet When a PE capable of flooding (say PEx) receives a broadcast Ethernet
frame, or one with an unknown destination MAC address, it must flood frame, or one with an unknown destination MAC address, it must flood
the frame. If the frame arrived from an attached CE, PEx must send a the frame. If the frame arrived from an attached CE, PEx must send a
copy of the frame to every other attached CE, as well as to all other copy of the frame to every other attached CE, as well as to all other
PEs participating in the VPLS. If, on the other hand, the frame PEs participating in the VPLS. If, on the other hand, the frame
arrived from another PE (say PEy), PEx must send a copy of the packet arrived from another PE (say PEy), PEx must send a copy of the packet
only to attached CEs. PEx MUST NOT send the frame to other PEs, only to attached CEs. PEx MUST NOT send the frame to other PEs,
since PEy would have already done so. This notion has been termed since PEy would have already done so. This notion has been termed
"split horizon" forwarding, and is a consequence of the PEs being "split horizon" forwarding and is a consequence of the PEs being
logically fully meshed for VPLS. logically fully meshed for VPLS.
Split horizon forwarding rules apply to broadcast and multicast Split horizon forwarding rules apply to broadcast and multicast
packets, as well as packets to an unknown MAC address. packets, as well as packets to an unknown MAC address.
4.2.6. Qualified and Unqualified Learning 4.2.6. Qualified and Unqualified Learning
The key for normal Ethernet MAC learning is usually just the The key for normal Ethernet MAC learning is usually just the
(6-octet) MAC address. This is called "unqualified learning". (6-octet) MAC address. This is called "unqualified learning".
However, it is also possible that the key for learning includes the However, it is also possible that the key for learning includes the
skipping to change at page 26, line 45 skipping to change at page 21, line 22
In the case of VPLS, learning is done in the context of a VPLS In the case of VPLS, learning is done in the context of a VPLS
instance, which typically corresponds to a customer. If the customer instance, which typically corresponds to a customer. If the customer
uses VLAN tags, one can make the same distinctions of qualified and uses VLAN tags, one can make the same distinctions of qualified and
unqualified learning. If the key for learning within a VPLS is just unqualified learning. If the key for learning within a VPLS is just
the MAC address, then this VPLS is operating under unqualified the MAC address, then this VPLS is operating under unqualified
learning. If the key for learning is (customer VLAN tag + MAC learning. If the key for learning is (customer VLAN tag + MAC
address), then this VPLS is operating under qualified learning. address), then this VPLS is operating under qualified learning.
Choosing between qualified and unqualified learning involves several Choosing between qualified and unqualified learning involves several
factors, the most important of which is whether one wants a single factors, the most important of which is whether one wants a single
global broadcast domain (unqualified), or a broadcast domain per VLAN global broadcast domain (unqualified) or a broadcast domain per VLAN
(qualified). The latter makes flooding and broadcasting more (qualified). The latter makes flooding and broadcasting more
efficient, but requires larger MAC tables. These considerations efficient, but requires larger MAC tables. These considerations
apply equally to normal Ethernet forwarding and to VPLS. apply equally to normal Ethernet forwarding and to VPLS.
4.2.7. Class of Service 4.2.7. Class of Service
In order to offer different Classes of Service within a VPLS, an In order to offer different Classes of Service within a VPLS, an
implementation MAY choose to map 802.1p bits in a customer Ethernet implementation MAY choose to map 802.1p bits in a customer Ethernet
frame with a VLAN tag to an appropriate setting of EXP bits in the frame with a VLAN tag to an appropriate setting of EXP bits in the
pseudowire and/or tunnel label, allowing for differential treatment pseudowire and/or tunnel label, allowing for differential treatment
of VPLS frames in the packet-switched network. of VPLS frames in the packet switched network.
To be useful, an implementation SHOULD allow this mapping function to To be useful, an implementation SHOULD allow this mapping function to
be different for each VPLS, as each VPLS customer may have their own be different for each VPLS, as each VPLS customer may have its own
view of the required behavior for a given setting of 802.1p bits. view of the required behavior for a given setting of 802.1p bits.
5. Deployment Options 5. Deployment Options
In deploying a network that supports VPLS, the SP must decide what In deploying a network that supports VPLS, the SP must decide what
functions the VPLS-aware device closest to the customer (the VE) functions the VPLS-aware device closest to the customer (the VE)
supports. The default case described in this document is that the VE supports. The default case described in this document is that the VE
is a PE. However, there are a number of reasons that the VE might be is a PE. However, there are a number of reasons that the VE might be
a device that does all the Layer 2 functions (such as MAC address a device that does all the Layer 2 functions (such as MAC address
learning and flooding), and a limited set of Layer 3 functions (such learning and flooding), and a limited set of Layer 3 functions (such
as communicating to its PE), but, for example, doesn't do full- as communicating to its PE), but, for example, doesn't do full-
fledged discovery and PE-to-PE signaling. Such a device is called a fledged discovery and PE-to-PE signaling. Such a device is called a
"u-PE". "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. For example, in a given provider network, one PE here allows this. For example, in a given provider network, one PE
may be directly connected to CE devices; another may be connected to may be directly connected to CE devices, another may be connected to
u-PEs that are connected to CEs; and a third may be connected u-PEs that are connected to CEs, and a third may be connected
directly to a customer over some interfaces and to u-PEs over others. directly to a customer over some interfaces and to u-PEs over others.
All these PEs perform discovery and signaling in the same manner. All these PEs perform discovery and signaling in the same manner.
How they do learning and forwarding depends on whether or not there How they do learning and forwarding depends on whether or not there
is a u-PE; however, this is a local matter, and is not 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 However, the details of the operation of a u-PE and its interactions
with PEs and other u-PEs is beyond the scope of this document. with PEs and other u-PEs are beyond the scope of this document.
6. 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 confidentiality, integrity, or authentication: VPLS does not offer confidentiality, integrity, or authentication: VPLS
packets are sent in the clear in the packet-switched network, and a packets are sent in the clear in the packet switched network, and a
man-in-the-middle can eavesdrop, and may be able to inject packets man-in-the-middle can eavesdrop, and may be able to inject packets
into the data stream. If security is desired, the PE-to-PE tunnels into the data stream. If security is desired, the PE-to-PE tunnels
can be IPsec tunnels. For more security, the end systems in the VPLS can be IPsec tunnels. For more security, the end systems in the VPLS
sites can use appropriate means of encryption to secure their data sites can use appropriate means of encryption to secure their data
even before it enters the Service Provider network. even before it 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 [2] 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 methods (b) and (c) described in Section 3, this also means
BGP sessions, between the ASBRs, the PEs or the Route Reflectors. protecting the inter-AS BGP sessions, between the ASBRs, the PEs, or
One can also use the techniques described in section 10 (b) and (c) the Route Reflectors. One can also use the techniques described in
of [6], both for the control plane and the data plane. Note that [2] Section 10 (b) and (c) of [6], both for the control plane and the
will not help in keeping VPLS labels private -- knowing the labels, data plane. Note that [2] will not help in keeping VPLS labels
one can eavesdrop on VPLS traffic. However, this requires access to private -- knowing the labels, one can eavesdrop on VPLS traffic.
the data path within a Service Provider network. However, this requires access to the data path within a Service
Provider network.
There can also be misconfiguration leading to unintentional There can also be misconfiguration leading to unintentional
connection of CEs in different VPLSs. This can be caused, for connection of CEs in different VPLSs. This can be caused, for
example, by associating the wrong Route Target with a VPLS instance. example, by associating the wrong Route Target with a VPLS instance.
This problem, shared by [6], is for further study. This problem, shared by [6], is for further study.
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
skipping to change at page 31, line 7 skipping to change at page 23, line 35
source addresses, packet filtering may not be effective unless the source addresses, packet filtering may not be effective unless the
egress PE can check the IP source address of any tunneled packet it egress PE can check the IP source address of any tunneled packet it
receives, and compare it to a list of IP addresses that are valid receives, and compare it to a list of IP addresses that are valid
tunnel head addresses. Any implementation that allows MPLS-in-IP tunnel head addresses. Any implementation that allows MPLS-in-IP
and/or MPLS-in-GRE tunneling to be used without IPsec MUST allow the and/or MPLS-in-GRE tunneling to be used without IPsec MUST allow the
egress PE to validate in this manner the IP source address of any egress PE to validate in this manner the IP source address of any
tunneled packet that it receives. tunneled packet that it receives.
7. IANA Considerations 7. IANA Considerations
IANA is asked to allocate an AFI for L2VPN information (suggested IANA allocated value (25) for AFI for L2VPN information. This should
value: 25). This should be the same as the AFI requested by [11]. be the same as the AFI requested by [11].
IANA is asked to allocate an extended community value for the Layer2 IANA allocated an extended community value (0x800a) for the Layer2
Info Extended Community (suggested value: 0x800a). Info Extended Community.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[3] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in [3] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in
IP or Generic Routing Encapsulation (GRE)", RFC 4023, IP or Generic Routing Encapsulation (GRE)", RFC 4023,
March 2005. March 2005.
[4] Bates, T., "Multiprotocol Extensions for BGP-4", [4] Bates, T., Katz, D., and Y. Rekhter, "Multiprotocol Extensions
draft-ietf-idr-rfc2858bis-10 (work in progress), March 2006. for BGP-4", RFC 4760, January 2007.
[5] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [5] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[6] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks [6] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006. (VPNs)", RFC 4364, February 2006.
[7] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, [7] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS "Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006. Networks", RFC 4448, April 2006.
8.2. Informative References 8.2. Informative References
[8] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An [8] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An
Alternative to Full Mesh IBGP", RFC 2796, April 2000. Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456,
April 2006.
[9] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [9] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05 Private Networks (L2VPNs)", RFC 4664, September 2006.
(work in progress), June 2004.
[10] Lasserre, M. and V. Kompella, "Virtual Private LAN Services [10] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN
Using LDP", draft-ietf-l2vpn-vpls-ldp-09 (work in progress), Service (VPLS) Using Label Distribution Protocol (LDP)
June 2006. Signaling", RFC 4762, January 2007.
[11] Ould-Brahim, H., "Using BGP as an Auto-Discovery Mechanism for [11] Ould-Brahim, H., "Using BGP as an Auto-Discovery Mechanism for
VR-based Layer-3 VPNs", draft-ietf-l3vpn-bgpvpn-auto-07 (work VR-based Layer-3 VPNs", Work in Progress, April 2006.
in progress), April 2006.
[12] Marques, P., "Constrained VPN Route Distribution", [12] Marques, P., "Constrained VPN Route Distribution", Work in
draft-ietf-l3vpn-rt-constrain-02 (work in progress), June 2005. Progress, June 2005.
[13] Martini, L., "Pseudowire Setup and Maintenance using the Label [13] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron,
Distribution Protocol", draft-ietf-pwe3-control-protocol-17 "Pseudowire Setup and Maintenance Using the Label Distribution
(work in progress), June 2005. Protocol (LDP)", RFC 4447, April 2006.
[14] Kompella, K., "Layer 2 VPNs Over Tunnels", [14] Kompella, K., "Layer 2 VPNs Over Tunnels", Work in Progress,
draft-kompella-l2vpn-l2vpn-01 (work in progress), January 2006. January 2006.
[15] Institute of Electrical and Electronics Engineers, "Information [15] Institute of Electrical and Electronics Engineers, "Information
technology - Telecommunications and information exchange technology - Telecommunications and information exchange
between systems - Local and metropolitan area networks - Common between systems - Local and metropolitan area networks - Common
specifications - Part 3: Media Access Control (MAC) Bridges: specifications - Part 3: Media Access Control (MAC) Bridges:
Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j- Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-
1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and 1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and
P802.12e. ISO/IEC 15802-3: 1998.", IEEE Standard 802.1D, P802.12e. ISO/IEC 15802-3: 1998.", IEEE Standard 802.1D,
July 1998. July 1998.
Appendix A. Contributors Appendix A. Contributors
The following contributed to this document: The following contributed to this document:
Javier Achirica, Telefonica Javier Achirica, Telefonica
Loa Andersson, Acreo Loa Andersson, Acreo
Chaitanya Kodeboyina, Juniper
Giles Heron, Tellabs Giles Heron, Tellabs
Sunil Khandekar, Alcatel Sunil Khandekar, Alcatel-Lucent
Vach Kompella, Alcatel Chaitanya Kodeboyina, Nuova Systems
Marc Lasserre, Riverstone Vach Kompella, Alcatel-Lucent
Marc Lasserre, Alcatel-Lucent
Pierre Lin Pierre Lin
Pascal Menezes 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
Appendix B. Acknowledgements Appendix B. Acknowledgements
Thanks to Joe Regan and Alfred Nothaft for their contributions. Many Thanks to Joe Regan and Alfred Nothaft for their contributions. Many
thanks too to Eric Ji, Chaitanya Kodeboyina, Mike Loomis and Elwyn thanks too to Eric Ji, Chaitanya Kodeboyina, Mike Loomis, and Elwyn
Davies for their detailed reviews. Davies for their detailed reviews.
Authors' Addresses Editors' Addresses
Kireeti Kompella (editor) Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: kireeti@juniper.net EMail: kireeti@juniper.net
Yakov Rekhter (editor) Yakov Rekhter
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: yakov@juniper.net EMail: yakov@juniper.net
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 37, line 29 skipping to change at page 28, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. 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 that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
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. 107 change blocks. 
383 lines changed or deleted 255 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/