draft-ietf-l2vpn-vpls-bgp-07.txt   draft-ietf-l2vpn-vpls-bgp-08.txt 
Network Working Group K. Kompella, Ed. Network Working Group K. Kompella, Ed.
Internet-Draft Y. Rekhter, Ed. Internet-Draft Y. Rekhter, Ed.
Expires: December 19, 2006 Juniper Networks Expires: December 23, 2006 Juniper Networks
June 17, 2006 June 21, 2006
Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and
Signaling Signaling
draft-ietf-l2vpn-vpls-bgp-07 draft-ietf-l2vpn-vpls-bgp-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 19, 2006. This Internet-Draft will expire on December 23, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Virtual Private LAN Service (VPLS), also known as Transparent LAN Virtual Private LAN (Local Area Network) Service (VPLS), also known
Service, and Virtual Private Switched Network service, is a useful as Transparent LAN Service, and Virtual Private Switched Network
Service Provider offering. The service offers a Layer 2 Virtual service, is a useful Service Provider offering. The service offers a
Private Network (VPN); however, in the case of VPLS, the customers in Layer 2 Virtual Private Network (VPN); however, in the case of VPLS,
the VPN are connected by a multipoint Ethernet Local Area Network the customers in the VPN are connected by a multipoint Ethernet LAN,
(LAN), in contrast to the usual Layer 2 VPNs, which are point-to- in contrast to the usual Layer 2 VPNs, which are point-to-point in
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document . . . . . . . . . . . . 5 1.2. Conventions used in this document . . . . . . . . . . . . 5
1.3. Changes from version 06 to 07 . . . . . . . . . . . . . . 5 1.3. Changes from version 06 to 07 . . . . . . . . . . . . . . 5
1.4. Changes from version 04 to 05 . . . . . . . . . . . . . . 6 1.4. Changes from version 05 to 06 . . . . . . . . . . . . . . 6
1.5. Changes from version 03 to 04 . . . . . . . . . . . . . . 6 1.5. Changes from version 04 to 05 . . . . . . . . . . . . . . 6
1.6. Changes from version 03 to 04 . . . . . . . . . . . . . . 7
2. Functional Model . . . . . . . . . . . . . . . . . . . . . . . 8 2. Functional Model . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Interactions . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Interactions . . . . . . . . . . . . . . . . . . . . . . . 9
3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Functions . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1. Functions . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Protocol Specification . . . . . . . . . . . . . . . . 12 3.1.2. Protocol Specification . . . . . . . . . . . . . . . . 12
3.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Label Blocks . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. PW Setup and Teardown . . . . . . . . . . . . . . . . 14 3.2.2. VPLS BGP NLRI . . . . . . . . . . . . . . . . . . . . 13
3.2.3. Signaling PE Capabilities . . . . . . . . . . . . . . 15 3.2.3. PW Setup and Teardown . . . . . . . . . . . . . . . . 14
3.2.4. Signaling PE Capabilities . . . . . . . . . . . . . . 15
3.3. BGP VPLS Operation . . . . . . . . . . . . . . . . . . . . 16 3.3. BGP VPLS Operation . . . . . . . . . . . . . . . . . . . . 16
3.4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . 17 3.4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . 17
3.4.1. a) VPLS-to-VPLS connections at the ASBRs. . . . . . . 18 3.4.1. a) VPLS-to-VPLS connections at the ASBRs. . . . . . . 18
3.4.2. b) EBGP redistribution of VPLS information between 3.4.2. b) EBGP redistribution of VPLS information between
ASBRs. . . . . . . . . . . . . . . . . . . . . . . . . 19 ASBRs. . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.3. c) Multi-hop EBGP redistribution of VPLS 3.4.3. c) Multi-hop EBGP redistribution of VPLS
information between ASes. . . . . . . . . . . . . . . 20 information between ASes. . . . . . . . . . . . . . . 20
3.4.4. Allocation of VE IDs Across Multiple ASes . . . . . . 20 3.4.4. Allocation of VE IDs Across Multiple ASes . . . . . . 20
3.5. Multi-homing and Path Selection . . . . . . . . . . . . . 21 3.5. Multi-homing and Path Selection . . . . . . . . . . . . . 21
3.6. Hierarchical BGP VPLS . . . . . . . . . . . . . . . . . . 21 3.6. Hierarchical BGP VPLS . . . . . . . . . . . . . . . . . . 21
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1. MAC address learning . . . . . . . . . . . . . . . . . 23 4.2.1. MAC address learning . . . . . . . . . . . . . . . . . 24
4.2.2. Flooding . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.2. Aging . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3. "Split Horizon" Forwarding . . . . . . . . . . . . . . 24 4.2.3. Flooding . . . . . . . . . . . . . . . . . . . . . . . 25
5. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 25 4.2.4. Broadcast and Multicast . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4.2.5. "Split Horizon" Forwarding . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 4.2.6. Qualified and Unqualified Learning . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.7. Class of Service . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 5. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 34 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 (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 offering. A Virtual Private LAN appears service offering. A Virtual Private LAN appears in (almost) all
in (almost) all respects as an Ethernet LAN to customers of a Service respects as an Ethernet LAN to customers of a Service Provider.
Provider. However, in a VPLS, the customers are not all connected to However, in a VPLS, the customers are not all connected to a single
a single LAN; the customers may be spread across a metro or wide LAN; the customers may be spread across a metro or wide area. In
area. In essence, a VPLS glues together several individual LANs essence, a VPLS glues together several individual LANs across a
across a packet-switched network to appear and function as a single packet-switched network to appear and function as a single LAN ([9]).
LAN ([9]). This is accomplished by incorporating MAC address learning, flooding
and forwarding functions in the context of pseudowires that connect
these individual LANs across the packet-switched network.
This document describes the functions needed to offer VPLS, and goes This document details the functions needed to offer VPLS, and then
on to describe a mechanism for signaling a VPLS, as well as a goes on to describe a mechanism for the autodiscovery of the
mechanism for transport of VPLS frames over tunnels across a packet endpoints of a VPLS as well as for signaling a VPLS. It also
switched network. The signaling mechanism uses BGP as the control describes how VPLS frames are transported over tunnels across a
plane protocol. This document also briefly discusses deployment packet switched network. The autodiscovery and signaling mechanism
options, in particular, the notion of decoupling functions across uses BGP as the control plane protocol. This document also briefly
devices. discusses deployment options, in particular, the notion of decoupling
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 one to set up an Ethernet connection across a packet-switched allows one to set up an Ethernet connection across a packet-switched
network. Both of these, however, offer point-to-point Ethernet network. Both of these, however, offer point-to-point Ethernet
services. What distinguishes VPLS from the above two is that a VPLS services. What distinguishes VPLS from the above two is that a VPLS
offers a multipoint service. A mechanism for setting up pseudowires offers a multipoint service. A mechanism for setting up pseudowires
for VPLS using the Label Distribution Protocol (LDP) is defined in for VPLS using the Label Distribution Protocol (LDP) is defined in
[10]. [10].
skipping to change at page 5, line 7 skipping to change at page 5, line 10
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 autodiscovery of VPLS
members and for the setup and teardown of the pseudowires that members and for the setup and teardown of the pseudowires that
constitute a given VPLS 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 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 Provider Edge routers is interaction of decoupled and non-decoupled PEs is described.
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 1.3. Changes from version 06 to 07
[NOTE to RFC Editor: this section is to be removed before [NOTE to RFC Editor: this section is to be removed before
skipping to change at page 6, line 16 skipping to change at page 6, line 19
6. Addressed (hopefully) by Sam's DISCUSS. 6. Addressed (hopefully) by Sam's DISCUSS.
7. Updated Security Considerations to incorporate the techniques 7. Updated Security Considerations to incorporate the techniques
described in RFC 4364 for inter-AS VPNs. Also, added a paragraph described in RFC 4364 for inter-AS VPNs. Also, added a paragraph
stating that misconfiguration could cause inter-VPLS connections, stating that misconfiguration could cause inter-VPLS connections,
just as can happen with RFC 4364. just as can happen with RFC 4364.
Updated references; added reference to RFC 4023. Updated references; added reference to RFC 4023.
1.4. Changes from version 04 to 05 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 [NOTE to RFC Editor: this section is to be removed before
publication.] publication.]
Updated IANA section to reflect agreement with authors of [11] that Updated IANA section to reflect agreement with authors of [11] that
the two docs should use the same AFI for L2VPN information. the two docs should use the same AFI for L2VPN information.
Addressed comments received from Alex Zinin. No technical changes, Addressed comments received from Alex Zinin. No technical changes,
but a more complete description to cover the issues that Alex raised: but a more complete description to cover the issues that Alex raised:
skipping to change at page 6, line 48 skipping to change at page 7, line 26
Changes to address these: Changes to address these:
1. Broke up section 3.2.1 into "Concepts" and "PW Setup". 1. Broke up section 3.2.1 into "Concepts" and "PW Setup".
2. Expanded section on "Signaling PE Capabilities". 2. Expanded section on "Signaling PE Capabilities".
3. Added a new section 3.3 "BGP VPLS Operation". 3. Added a new section 3.3 "BGP VPLS Operation".
4. Minor tweaking, e.g. to fix section number references. 4. Minor tweaking, e.g. to fix section number references.
1.5. Changes from version 03 to 04 1.6. Changes from version 03 to 04
[NOTE to RFC Editor: this section is to be removed before [NOTE to RFC Editor: this section is to be removed before
publication.] publication.]
Incorporated IDR review comments from Eric Ji, Chaitanya Kodeboyina, Incorporated IDR review comments from Eric Ji, Chaitanya Kodeboyina,
and Mike Loomis. Most changes are clarifications and rewording for and Mike Loomis. Most changes are clarifications and rewording for
better readability. The substantive changes are to remove several better readability. The substantive changes are to remove several
flags from the control field. 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.
----- -----
skipping to change at page 9, line 31 skipping to change at page 9, line 31
tunnels, established by RSVP-TE or LDP. These tunnels are tunnels, established by RSVP-TE or LDP. These tunnels are
established independently of the services offered over them; the established independently of the services offered over them; the
signaling and establishment of these tunnels are not discussed in signaling and establishment of these tunnels are not discussed in
this document. this document.
"Flooding" and MAC address "learning" (see Section 4) are an integral "Flooding" and MAC address "learning" (see Section 4) are an integral
part of VPLS. However, these activities are private to an SP device, part of VPLS. However, these activities are private to an SP device,
i.e., in the VPLS described below, no SP device requests another SP i.e., in the VPLS described below, no SP device requests another SP
device to flood packets or learn MAC addresses on its behalf. device to flood packets or learn MAC addresses on its behalf.
All the PEs participating in a VPLS are assumed to be fully meshed All the PEs participating in a VPLS are assumed to be fully meshed in
with pseudowires specific to that VPLS, i.e., every (ingress) PE can the data plane, i.e., there is a bidirectional pseudowire between
send a VPLS packet to the egress PE(s) directly, without the need for every pair of PEs participating in that VPLS, and thus every
an intermediate PE (see Section 4.2.3.) This places a stringent (ingress) PE can send a VPLS packet to the egress PE(s) directly,
requirement on VPLS signaling (see Section 3.6.) without the need for an intermediate PE (see Section 4.2.5.) This
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
necessary pseudowires. See Section 3.6 for a discussion on
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 VPLS V can
interact through the SP network as if they were connected by a LAN. interact through the SP network as if they were connected by a LAN.
VPLS is "private" in that CE devices that belong to different VPLSs VPLS is "private" in that CE devices that belong to different VPLSs
cannot interact. VPLS is "virtual" in that multiple VPLSs can be cannot interact. VPLS is "virtual" in that multiple VPLSs can be
offered over a common packet switched network. offered over a common packet switched network.
PE devices interact to "discover" all the other PEs participating in PE devices interact to "discover" all the other PEs participating in
skipping to change at page 11, line 20 skipping to change at page 11, line 20
Section 3.2 describe these functions. Both of these functions are Section 3.2 describe these functions. Both of these functions are
accomplished with a single BGP Update advertisement; Section 3.3 accomplished with a single BGP Update advertisement; Section 3.3
describes how this is done by detailing BGP protocol operation for describes how this is done by detailing BGP protocol operation for
VPLS. Section 3.4 describes the setting up of pseudowires that span VPLS. 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. Autodiscovery
Discovery refers to the process of finding all the PEs that Discovery refers to the process of finding all the PEs that
participate in a given VPLS. A PE can either be configured with the participate in a given VPLS instance. A PE can either be configured
identities of all the other PEs in a given VPLS, or the PE can use with the identities of all the other PEs in a given VPLS, or the PE
some protocol to discover the other PEs. The latter is called can use some protocol to discover the other PEs. The latter is
autodiscovery. called autodiscovery.
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 autodiscovery approach, each PE "discovers" which other PEs
are part of a given VPLS by means of some protocol, in this case BGP. are part of a given VPLS by means of some protocol, in this case BGP.
This allows each PE's configuration to consist only of the identity This allows each PE's configuration to consist only of the identity
of the VPLS 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 V must be able to tell all A PE that participates in a given VPLS instance V must be able to
other PEs in VPLS V that it is also a member of V. A PE must also tell all other PEs in VPLS V that it is also a member of V. A PE must
have a means of declaring that it no longer participates in a VPLS. also have a means of declaring that it no longer participates in a
To do both of these, the PE must have a means of identifying a VPLS VPLS. To do both of these, the PE must have a means of identifying a
and a means by which to communicate to all other PEs. 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 autodiscovery 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
skipping to change at page 12, line 51 skipping to change at page 13, line 5
Using a distinct BGP Update message to send a demultiplexor to each Using a distinct BGP Update message to send a demultiplexor to each
remote PE would require the originating PE to send N such messages remote PE would require the originating PE to send N such messages
for N remote PEs. The solution described in this document allows a for N remote PEs. The solution described in this document allows a
PE to send a single (common) Update message that contains PE to send a single (common) Update message that contains
demultiplexors for all the remote PEs, instead of N individual demultiplexors for all the remote PEs, instead of N individual
messages. Doing this reduces the control plane load both on the messages. Doing this reduces the control plane load both on the
originating PE as well as on the BGP Route Reflectors that may be originating PE as well as on the BGP Route Reflectors that may be
involved in distributing this Update to other PEs. involved in distributing this Update to other PEs.
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 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 their
(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 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, LB+
VBO+1, ..., LB+VBO+VBS-1}. Thus, instead of a single large label 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 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.1. Concepts 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 exact format is Block Offset, a VE Block Size and a label base. The format of the
given below. VPLS NLRI is given below. The AFI is the L2VPN AFI (to be assigned
by IANA), and the SAFI is the VPLS SAFI (65). The Length field is in
octets.
+------------------------------------+
| Length (2 octets) |
+------------------------------------+
| Route Distinguisher (8 octets) |
+------------------------------------+
| VE ID (2 octets) |
+------------------------------------+
| VE Block Offset (2 octets) |
+------------------------------------+
| VE Block Size (2 octets) |
+------------------------------------+
| Label Base (3 octets) |
+------------------------------------+
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 implicitly announces 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 correspondance 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.2. 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 V, VE Block Offset VBO, VE Block Size VBS and label base LB. If ID 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. is W part of PE-a's 'remote VE set': if VBO <= W < VBO + VBS, 1. checks if W is part of PE-a's 'remote VE set': if VBO <= W < VBO
then W is part of PE-a's remote VE set. If not, PE-b ignores + VBS, then W is part of PE-a's remote VE set. If not, PE-b
this message, and skips the rest of this procedure. ignores this message, and skips the rest of this procedure.
2. set up a PW to PE-a: the demultiplexor label to send traffic from 2. sets up a PW to PE-a: the demultiplexor label to send traffic
PE-b to PE-a is computed as (LB + W - VBO). from PE-b to PE-a is computed as (LB + W - VBO).
3. is V part of any 'remote VE set' that PE-b announced: PE-b checks 3. checks if V is part of any 'remote VE set' that PE-b announced,
if V belongs to some remote VE set that PE-b announced, say with i.e., PE-b checks if V belongs to some remote VE set that PE-b
VE Block Offset VBO', VE Block Size VBS' and label base LB'. If announced, say with VE Block Offset VBO', VE Block Size VBS' and
not, PE-b MUST make a new announcement as described in label base LB'. If not, PE-b MUST make a new announcement as
Section 3.3. described in Section 3.3.
4. set 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.
The format of the VPLS NLRI is given below. The AFI is the L2VPN AFI 3.2.4. Signaling PE Capabilities
(to be assigned by IANA), and the SAFI is the VPLS SAFI (65). The
Length field is in octets.
+------------------------------------+
| Length (2 octets) |
+------------------------------------+
| Route Distinguisher (8 octets) |
+------------------------------------+
| VE ID (2 octets) |
+------------------------------------+
| VE Block Offset (2 octets) |
+------------------------------------+
| VE Block Size (2 octets) |
+------------------------------------+
| Label Base (3 octets) |
+------------------------------------+
Figure 2: BGP NLRI for VPLS Information
3.2.3. 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.
skipping to change at page 16, line 16 skipping to change at page 16, line 16
| 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 If set to 1 (0), Control word MUST (NOT) be present when C A Control word (
sending VPLS packets to this PE [10]. [7]
S If set to 1 (0), Sequenced delivery of frames is (not) ) MUST or MUST NOT be present when
required when sending VPLS packets to this PE. sending VPLS packets to this PE, depending on whether C
is 1 or 0, respectively
S Sequenced delivery of frames MUST or MUST NOT be used
when sending VPLS packets to this PE. depending on
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 a 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);
skipping to change at page 16, line 48 skipping to change at page 17, line 4
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 (auto-discovery). PE-a then has to set up its part of a VPLS VPLS (autodiscovery). 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
skipping to change at page 17, line 33 skipping to change at page 17, line 36
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 autodiscovery and signaling functions
are typically announced via I-BGP. This assumes that all the sites are typically announced via I-BGP. This assumes that all the sites
in a VPLS are connected to PEs in a single Autonomous System (AS). in a VPLS are connected to PEs in a single Autonomous System (AS).
However, sites in a VPLS may connect to PEs in different ASes. This However, sites in a VPLS may connect to PEs in different ASes. This
leads to two issues: 1) there would not be an I-BGP connection leads to two issues: 1) there would not be an I-BGP connection
between those PEs, so some means of signaling across ASes may be between those PEs, so some means of signaling across ASes is needed;
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
multi-AS VPLS. multi-AS VPLS.
Here is a diagram for reference: Here is a diagram for reference:
__________ ____________ ____________ __________ __________ ____________ ____________ __________
/ \ / \ / \ / \ / \ / \ / \ / \
\___/ AS 1 \ / AS 2 \___/ \___/ AS 1 \ / AS 2 \___/
skipping to change at page 18, line 26 skipping to change at page 18, line 26
\__________/ \____________/ \____________/ \__________/ \__________/ \____________/ \____________/ \__________/
Figure 6: Inter-AS VPLS Figure 6: 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
Method (c) requires MPLS on the AS-AS interconnect, but no VPLS state (which need not be Ethernet). Method (c) requires MPLS on the AS-AS
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. 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
skipping to change at page 22, line 8 skipping to change at page 22, line 8
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 which 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 of 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 requires a large number of
RRs, then this technique can be applied recursively: the full mesh RRs, 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].
The problem of limiting BGP VPLS message passing to just the Another consequence of this approach is that it is not required that
interested BGP speakers is addressed by the use of Route Target one set of RRs handles all BGP messages, or that a particular RR
Filtering, described in [12]. This technique is orthogonal to the handle all messages from a given PE. One can define several sets of
use of RRs, but works well in conjunction with RRs. RRs, for example a set to handle VPLS, another to handle IP VPNs and
another for Internet routing. Another partitioning could be to 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;
the use of Route Target Filtering (RTF), described in [12] can make
this simpler and more effective.
It is not required that a given set of RRs handle all BGP messages. Finally, problem 2 (that of limiting BGP VPLS message passing to just
One can define several sets of RRs, for example a set to handle VPLS, the interested BGP speakers) is addressed by the use of RTF. This
another to handle IP VPNs and another for Internet routing. Another technique is orthogonal to the use of RRs, but works well in
partitioning could be to have one subset of VPLSs and IP VPNs handled conjunction with RRs. RTF is also very effective in inter-AS VPLS;
by one set of RRs, and another subset of VPLSs and IP VPNs handled by more details on how RTF works and its benefits are provided in [12].
another set of RRs; this can be accomplished by the use of Route
Target Filtering.
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 auto- by each PE. The only task of BGP VPLS message exchange is
discovery and label exchange. This means that once a PE joins a VPLS autodiscovery and label exchange.
and sends an update indicating this (and the labels to use), that PE
sends no more BGP updates for that VPLS until either the PE leaves Thus, BGP processing for VPLS occurs when
that VPLS, or a fairly serious event (such as a PE-CE link going
down) occurs. 1. a PE joins or leaves a VPLS; or
2. a failure occurs in the network, bringing down a PE-PE tunnel or
a PE-CE link.
These events are relatively rare, and typically, each such event
causes one BGP update to be generated. Coupled with BGP's messaging
efficiency when used for signaling VPLS, these observations lead to
the conclusion that BGP as a control plane for VPLS will scale quite
well both in terms of 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 23, line 31 skipping to change at page 24, line 31
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 on all of the VE on a given the SP "bridge" are the customer ports as well as the pseudowires on
service. Just as a learning bridge learns MAC addresses on its a VE. Just as a learning bridge learns MAC addresses on its ports,
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 bridge
receives a packet with destination MAC address S, it knows that it receives a packet with destination MAC address S, it knows that it
should send the packet out on port P. should send the packet out on port P.
4.2.2. Flooding 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
reflect the new port P'. A VE MAY implement a mechanism to damp
flapping of source ports for a given MAC address.
4.2.2. Aging
VPLS PEs SHOULD have an aging mechanism to remove a MAC address
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"
from a logical port to another logical port, either because the
station to which that MAC address belongs really has moved, or
because of a topology change in the LAN that causes this MAC address
to arrive on a new port. In addition, aging reduces the size of a
VPLS MAC table to just the active MAC addresses, rather than all MAC
addresses in that VPLS.
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
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,
S's age is reset.
An implementation SHOULD provide a configurable knob to set the aging
time T on a per-VPLS basis. In addition, an implementation MAY
accelerate aging of all MAC addresses in a VPLS if it detects certain
situations, such as a Spanning Tree topology change in that VPLS.
4.2.3. Flooding
When a bridge receives a packet to a destination that is not in its When a bridge receives a packet to a destination that is not in its
FIB, it floods the packet on all the other ports. Similarly, a VE FIB, it floods the packet on all the other ports. Similarly, a VE
will flood packets to an unknown destination to all other VEs in the will flood packets to an unknown destination to all other VEs in the
VPLS. VPLS.
In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the
destination MAC address on the frame was not in PE2's FIB (for that destination MAC address on the frame was not in PE2's FIB (for that
VPLS), then PE2 would be responsible for flooding that frame to every VPLS), then PE2 would be responsible for flooding that frame to every
other PE in the same VPLS. On receiving that frame, PE1 would be other PE in the same VPLS. On receiving that frame, PE1 would be
skipping to change at page 24, line 16 skipping to change at page 25, line 44
knew which CE "owned" that MAC address). knew which CE "owned" that MAC address).
On the other hand, if PE3 received the frame, it could delegate On the other hand, if PE3 received the frame, it could delegate
further flooding of the frame to its u-PE. If PE3 was connected to 2 further flooding of the frame to its u-PE. If PE3 was connected to 2
u-PEs, it would announce that it has two u-PEs. PE3 could either u-PEs, it would announce that it has two u-PEs. PE3 could either
announce that it is incapable of flooding, in which case it would announce that it is incapable of flooding, in which case it would
receive two frames, one for each u-PE, or it could announce that it receive two frames, one for each u-PE, or it could announce that it
is capable of flooding, in which case it would receive one copy of is capable of flooding, in which case it would receive one copy of
the frame, which it would then send to both u-PEs. the frame, which it would then send to both u-PEs.
4.2.3. "Split Horizon" Forwarding 4.2.4. Broadcast and Multicast
When a PE capable of flooding receives a broadcast Ethernet frame, or There is a well-known broadcast MAC address. An Ethernet frame whose
one with an unknown destination MAC address, it must flood the frame. destination MAC address is the broadcast MAC address must be sent to
If the frame arrived from an attached CE, the PE must send a copy of all stations in that VPLS. This can be accomplished by the same
the frame to every other attached CE, as well as to all PEs means that is used for flooding.
participating in the VPLS. If the frame arrived from another PE,
however, the PE must only send a copy of the packet to attached CEs.
The PE MUST NOT send the frame to other PEs. This notion has been
termed "split horizon" forwarding, and is a consequence of the PEs
being logically fully meshed -- if a broadcast frame is received from
PEx, then PEx would have sent a copy to all other PEs.
Split horizon forwarding rules also apply to multicast frames (i.e., There is also an easily recognized set of "multicast" MAC addresses.
those with a multicast destination MAC address). In this case, when
a PE receives a multicast frame from another PE, the frame is Ethernet frames with a destination multicast MAC address MAY be
replicated and sent to the relevant subset of attached CEs; however, broadcast to all stations; a VE MAY also use certain techniques to
it MUST NOT be sent to other PEs. restrict transmission of multicast frames to a smaller set of
receivers, those that have indicated interest in the corresponding
multicast group. Discussion of this is outside the scope of this
document.
4.2.5. "Split Horizon" Forwarding
When a PE capable of flooding (say PEx) receives a broadcast Ethernet
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
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
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,
since PEy would have already done so. This notion has been termed
"split horizon" forwarding, and is a consequence of the PEs being
logically fully meshed for VPLS.
Split horizon forwarding rules apply to broadcast and multicast
packets, as well as packets to an unknown MAC address.
4.2.6. Qualified and Unqualified Learning
The key for normal Ethernet MAC learning is usually just the
(6-octet) MAC address. This is called "unqualified learning".
However, it is also possible that the key for learning includes the
VLAN tag when present; this is called "qualified learning".
In the case of VPLS, learning is done in the context of a VPLS
instance, which typically corresponds to a customer. If the customer
uses VLAN tags, one can make the same distinctions of qualified and
unqualified learning. If the key for learning within a VPLS is just
the MAC address, then this VPLS is operating under unqualified
learning. If the key for learning is (customer VLAN tag + MAC
address), then this VPLS is operating under qualified learning.
Choosing between qualified and unqualified learning involves several
factors, the most important of which is whether one wants a single
global broadcast domain (unqualified), or a broadcast domain per VLAN
(qualified). The latter makes flooding and broadcasting more
efficient, but requires larger MAC tables. These considerations
apply equally to normal Ethernet forwarding and to VPLS.
4.2.7. Class of Service
In order to offer different Classes of Service within a VPLS, an
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
pseudowire and/or tunnel label, allowing for differential treatment
of VPLS frames in the packet-switched network.
To be useful, an implementation SHOULD allow this mapping function to
be different for each VPLS, as each VPLS customer may have their own
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-
 End of changes. 44 change blocks. 
156 lines changed or deleted 285 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/