PPVPN Working Group K. Kompella (Juniper)
Internet Draft Y. Rekhter (Juniper)
Expiration Date: May 2002 V. Kompella (TiMetra)
J. Achirica (Telefonica)
L. Andersson (Utfors)
G. Heron (PacketExchange)
S. Khandekar (TiMetra)
M. Lasserre (Riverstone)
P. Lin (Yipes)
P. Menezes (Terabeam)
A. Moranganti (Appian)
H. Ould-Brahim (Nortel)
S. Yeong-il (Korea Tel)
Virtual Private LAN Service
draft-kompella-ppvpn-vpls-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
K. Kompella (editor) Expires May 2002 [Page 1]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
2. Abstract
Virtual Private LAN Service (VPLS), also known as Transparent LAN
Service, and Virtual Private Switched Network service, is a useful
Service Provider offering. The service offered is a Layer 2 VPN;
however, in the case of VPLS, the customers in the VPN are connected
by a multipoint network; this is in contrast to the usual Layer 2
VPNs, which are point-to-point in nature.
This document describes the functions needed to offer VPLS, and goes
on to propose a mechanism for signaling a VPLS, as well as a
mechanism for transport of VPLS frames over tunnels across a packet
switched network.
3. Introduction
Virtual Private LAN Service (VPLS), also known as Transparent LAN
Service, and Virtual Private Switched Network service, is a useful
Service offering. A Virtual Private LAN appears in (almost) all
respects as a LAN to the Service Provider customer. 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 essence, a
VPLS glues several individual LANs across a metro area to appear and
function as a single LAN [VPLS-REQ].
This document describes the functions needed to offer VPLS, and goes
on to propose a mechanism for signaling a VPLS, as well as a
mechanism for transport of VPLS frames over tunnels across a packet
switched network. The basic framework is taken from [L2VPN].
Section 3 describes the functions needed to offer a VPLS, and several
deployment scenarios. Section 4 describes a common mechanism for
VPLS discovery and signaling, as well as transport of frames.
Section 5 depicts an example where the VPLS functions are split
across two types of devices.
It is important to point out that [L2VPN] allows one to build a Layer
2 VPN with Ethernet as the interconnect; and [MART-SIG] allows one to
signal an Ethernet connection across a packet switched network. Both
of these, however, offer point-to-point Ethernet services. What
distinguishes VPLS from the above two is that VPLS offers a
multipoint service. Furthermore, it is useful to note that LDP
signaling for a VPLS is defined in [VPLS-LDP]; however, LDP does not
offer a scalable VPN discovery mechanism.
K. Kompella (editor) Expires May 2002 [Page 2]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
4. VPLS functional architecture
This will be described with reference to Figure 1.
Figure 1: Example of a VPLS
-----
/ A1 \
---- ____CE1 |
/ \ -------- -------- / | |
| A2 CE2- / \ / PE1 \ /
\ / \ / \___/ | \ -----
---- ---PE2 | \
| | \ -----
| Service Provider Network | \ / \
| | CE5 A5 |
| ___ | / \ /
|----| \ / \ PE4_/ -----
|L2PE|--PE3 / \ /
|----| -------- -------
---- / | ----
/ \/ \ / \ CE = Customer Edge Device
| A3 CE3 --CE4 A4 | PE = Provider Edge Router
\ / \ / L2PE = Layer 2 Aggregation
---- ----
The terminology of [L2VPN] is used, with the addition of "L2PE", a
Layer 2 PE device used for Layer 2 aggregation. An L2PE is owned and
operated by the Service Provider (as is the PE). PE and L2PE devices
are "VPLS-aware", which means that they know that a VPLS service is
being offered. We will call these VPLS edge devices, which could be
either a PE or an L2PE, a VE.
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
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
device, either to the hardware or the software, in order to offer
VPLS.
Note that a CE device may be connected to a PE or an L2PE via Layer 2
switches that are VPLS-unaware. From a VPLS point of view, such
Layer 2 switches are invisible, and hence will not be discussed
further. Furthermore, an L2PE may be connected to a PE via Layer 2
and Layer 3 devices; this will be discussed further in a later
section.
The Service Provider Network is a packet switched network. It is
desirable that the links in this network are independent of the
K. Kompella (editor) Expires May 2002 [Page 3]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
services (in particular, VPLS) being offered. The PEs are assumed to
be full meshed with tunnels; these tunnels can be GRE, RSVP-TE or LDP
tunnels. The signaling and establishment of these tunnels is not
discussed in this document.
4.1. VPLS functions
A VPLS offers a multipoint Layer 2 service over tunnels across a
common packet switched network. This requires the following
functional elements:
1) Endpoint discovery
2) Signaling for tunnel multiplexing
3) MAC address learning
4) Flooding
5) Spanning tree
4.1.1. VPLS endpoint discovery
Endpoint discovery is the process by which the VPLS-aware devices
find all the customers' ports that belong to the same VPLS. More
specifically, a given PE that has one or more (customers') ports that
belong to a particular VPLS needs to know all other PEs that have one
or more ports that belong to the same VPLS. In the example given
above, this means that PE1, PE2, PE3 and PE4 find out that CE1-5 all
belong to one VPLS, and that each PE knows to which PE CEx is
attached.
L2PE devices also need to know what constitutes a given VPLS;
however, they don't need the same level of detail. The PE (or PEs)
to which an L2PE is connected gives the L2PE an abstraction of the
VPLS; this is accomplished by means of the protocol described in
[DTLS].
Note that an endpoint in a VPLS is a VE.
4.1.2. Signaling for tunnel multiplexing
For reasons of scalability, both of network state as well as SP
manageability, there is a single mesh of PE-to-PE tunnels. This
means that each tunnel may have multiple services running over it.
In order to multiplex these services over a given tunnel (and to know
which service a packet belongs to at the egress), one must signal a
tunnel multiplexor.
K. Kompella (editor) Expires May 2002 [Page 4]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
As in [L2VPN] and [L2SIG], the multiplexor proposed here is a 32 bit
cookie formatted as an MPLS label. At the egress, this label
captures both the VPLS to which the packet belongs, as well as the
source VE.
4.1.3. MAC address learning
As was mentioned earlier, the key distinguishing feature of VPLS is
that it is a multipoint service. This means that the entire Service
Provider network should appear as a single logical learning bridge
for each VPLS that the SP network supports. The logical ports for
the SP "bridge" are the connections from the SP edge, be it a PE or
an L2PE, to the CE. Just as a learning bridge learns MAC addresses
on its ports, the SP bridge must learn MAC addresses at its VEs
[VPLS].
Learning consists of associating source MAC addresses of packets with
the ports on which they arrive; call this association the Forwaring
Information Base (FIB). The FIB is used for forwarding packets. For
example, suppose the bridge receives a packet with source MAC address
S on port P. If subsequently, the bridge receives a packet with
destination MAC address S, it knows that it should send the packet
out on port P.
There are two modes of learning: qualified and unqualified learning.
In qualified learning, the learning decisions at the VE are based on
the customer ethernet packet's MAC address and VLAN tag, if one
exists. If no VLAN tag exists, the default VLAN is assumed.
Effectively, within one VPLS, there are multiple logical FIBs, one
for each customer VLAN tag identified in a customer packet.
In unqualified learning, learning is based on a customer ethernet
packet's MAC address only. In other words, at any VE, there is only
one FIB per VPLS.
Every VE must have at least one FIB for each VPLS that it
participates in.
4.1.4. Flooding
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
will flood packets to an unknown destination to all other VEs in the
VPLS.
K. Kompella (editor) Expires May 2002 [Page 5]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
In the example above (Figure 1), if CE2 sent an Ethernet frame to
PE2, and the 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 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 knew which CE "owned" that MAC address).
On the other hand, if PE3 received the frame, it could delegate
further flooding of the frame to its L2PE. If PE3 was connected to 2
L2PEs, it would announce that it has two L2PEs. PE3 could either
announce that it is incapable of flooding, in which case it would
receive two frames, one for each L2PE, or it could announce that it
is capable of flooding, in which case it would receive one copy of
the frame, which it would then send to both L2PEs.
4.1.5. Spanning tree
Learning bridges typically run STP to avoid flooding loops. However,
running an instance of STP for each VPLS doesn't scale. By mandating
a full mesh of PE-to-PE tunnels, we obviate the need for STP across
the Service Provider network.
If one considers a VPLS as a "VPLS bridge", then care must be taken
to avoid formation of forwarding loops if such VPLS bridges are
directly interconnected (with no STP-running bridges in between).
4.2. Functional decomposition
The above functions needed to implement a VPLS can be broadly divided
into Layer 3 functions (discovery and signaling) and Layer 2
functions (MAC learning, flooding and (if needed) spanning tree.
These functions need not all run on the same box. The terminology of
PE and L2PE was introduced to allow for a decomposition of VPLS
functions.
A PE does discovery and signaling. The VE does learning and
flooding. If the VE is a PE, then all the above functions reside on
a single box. If the VE is an L2PE, then there is a decoupling of
the functions along the lines described above. For a more detailed
description of the latter case, see [DTLS].
It might be possible in some cases where the VE is an L2PE to have
the L2PE do just the MAC learning, and have the PE do the flooding,
if the PE is capable of packet replication. This allows the L2PE to
send a single packet to the PE, conserving the L2PE-PE link
bandwidth.
K. Kompella (editor) Expires May 2002 [Page 6]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
This document proposes that the mechanisms of [L2VPN] be used for
discovery and signaling, with minor modifications described in the
next section. Furthermore, the operation of discovery and signaling
should be independent of whether the VPLS functions run on the same
box or different boxes. This allows an SP to "mix and match" PEs and
PE-L2PE combinations as needed at each site.
5. Discovery and signaling
As mentioned above, the mechanism for discovery and signaling is
based on [L2VPN]. The modification needed to support VPLS are:
1) re-interpretation of the "CE ID" field
2) new Encaps Types to support VPLS
3) a new control flag for "Flooding capable" PEs
4) a new sub-TLV for Relearning Sequence Numbers
5.1. VE ID
A PE advertises a VPLS NLRI for each VPLS that it participates in.
If the PE is doing learning and flooding, i.e., it is the VE, it
announces a single VPLS NLRI for each VPLS that it is in. If the PE
is connected to several L2PEs, it announces one VPLS NLRI for each
L2PE. A hybrid scheme is also possible, where the PE learns MAC
addresses on some interfaces (over which it is directly connected to
CEs) and delegates learning on other interfaces (over which it is
connected to L2PEs). In this case, the PE would announce one VPLS
NLRI for each L2PE that has customer ports in a given VPLS, and one
for itself, if it has customer ports in that VPLS.
The format of the VPLS NLRI is given below; it is essentially
identical to the L2 VPN NLRI. The AFI and SAFI are the same as for
the L2 VPN NLRI.
5.2. Relearn Sequence Number
Once a MAC address has been learned by VE A, VE A no longer needs to
flood packets destined to that MAC address; instead VE A can send
those packets directly to the VE "owning" that MAC address, VE B.
However, it is possible that a CE "move" from VE B to VE C; one
example scenario is that the CE is dual-homed to VE B and C, and the
link over which it is attached to VE B goes down. In this case, VE B
may want to signal to other VEs in the VPLS that MAC addresses that
they learned from VE B (for the given VPLS) are no longer valid.
While aging timers will eventually enforce this, they may often be
K. Kompella (editor) Expires May 2002 [Page 7]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
Figure 2: BGP NLRI for VPLS Information
+------------------------------------+
| Length (2 octets) |
+------------------------------------+
| Route Distinguisher (8 octets) |
+------------------------------------+
| VE ID (2 octets) |
+------------------------------------+
| Label-block Offset (2 octets) |
+------------------------------------+
| Label Base (3 octets) |
+------------------------------------+
| Variable TLVs (0 to N octets) |
| ... |
+------------------------------------+
too slow. The Relearn Sequence Number (RSN) TLV will help speed up
relearning.
5.2.1. RSN TLV
This is an optional TLV with Type TBD, Length 4 and Value a 32 bit
RSN, is a monotonically increasing unsigned number. When an RSN TLV
is received, the RSN number is compared against the existing one for
that VPLS and PE. If the new number is higher than the previous one,
or no previous RSN exists, the PE SHOULD flush all existing MAC
address to VC bindings for that VPLS and PE.
5.3. Encaps Type and Control Flags
The Encaps Type and Control Flags are encoded in an extended
attribute, just as in [L2VPN]. The community type remains the same.
There is a new Encaps Type for VPLS (TBD).
There are two new control flags, Q and F defined for VPLS. Q says
whether qualified learning occurs (1) or not (0); F which says
whether the PE is capable of flooding (1) or not (0).
K. Kompella (editor) Expires May 2002 [Page 8]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
Figure 3: layer2-info extended community
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octet) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
Figure 4: Control Flags Bit Vector
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |Q|F|C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
6. VPLS encapsulation
Ethernet frames received from a CE are encapsulated as in [MART-ENC]
with the following changes:
- if the packet, as it arrives at the PE, has a "service tag", e.g.,
a VLAN tag that is used by the local PE as a service delimiter,
then that tag is stripped before the packet is sent into the VPLS.
As the packet exits the VPLS, the packet may have a new service
tag inserted; this is a local decision on the egress PE.
- if the packet, as it arrives at the PE, has an encapsulation that
is not service-delimiting (i.e., it has no VLAN that was imposed by
the SP to distinguish services, then it is a customer packet whose
encapsulation should not be modified by the VPLS. This covers, for
example, a packet that carries customer specific tags that the
service provider neither knows about nor wants to modify. The
egress PE should likewise send the packet to the CE unmodified.
By following the above rules, the ethernet packet that traverses a
VPLS is always a customer ethernet packet. Note that the two
actions, at ingress and egress, of dealing with service delimiters
are local actions that neither PE has to signal to the other. They
allow, for example, a mix-and-match of tagged and untagged services
at either end, and do not carry across a VPLS a tag that may have
K. Kompella (editor) Expires May 2002 [Page 9]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
only local significance. The service delimiter may be a VC label
also, whereby an ethernet VC given by [MART-ENC] can serve as the
access side connection into a PE. An RFC1483 PVC encapsulation could
be another service delimiter.
7. Security Considerations
The security aspects of this solution will be discussed at a later
time.
8. IANA Considerations
(To be filled in in a later revision.)
9. Acknowledgments
Thanks to Joe Regan and Alfred Nothaft for their contributions.
10. References
[DTLS] Kompella, K., et al, "Decoupled TLS", work in progress.
[L2VPN] Kompella, K., et al, "MPLS-based Layer 2 VPNs", work in
progress.
[MART-ENC] Martini, L., et al, "Encapsulation Methods for Transport
of Layer 2 Frames Over IP and MPLS Networks", work in progress.
[MART-SIG] Martini, L., et al, "Transport of Layer 2 Frames Over
MPLS", work in progress.
[VPLS-LDP] Kompella, V., et al, "Virtual Private Switched Network
Services over an MPLS Network", work in progress.
[VPLS-REQ] Augustyn et al, "Requirements for Virtual Private LAN
Services (VPLS)", work in progress.
K. Kompella (editor) Expires May 2002 [Page 10]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
11. Intellectual Property Considerations
Juniper Networks may seek patent or other intellectual property
protection for some of all of the technologies disclosed in this
document. If any standards arising from this document are or become
protected by one or more patents assigned to Juniper Networks,
Juniper intends to disclose those patents and license them on
reasonable and non-discriminatory terms.
12. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
K. Kompella (editor) Expires May 2002 [Page 11]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
13. Author Information
Yeong-il,Seo
Korea Telecom
Telecommunication Network Laboratory
Member of Technical Staff
463-1 Junmin-dong, Yusung-gu, Taejeon, Korea
Tel : +82-42-870-8333 / FAX : +82-42-870-8339
Mobile : 016-235-0135 / E-mail : syi@hana.ne.kr
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
Email: hbrahim@nortelnetworks.com
Ashwin Moranganti
Appian Communications
email: amoranganti@appiancom.com
phone: 978 206-7248
Pascal Menezes
Terabeam Networks, Inc.
14833 NE 87th St.
Redmond, WA, USA
phone: (206) 686-2001
email: Pascal.Menezes@Terabeam.com
Pierre Lin
Yipes Communications, Inc.
114 Sansome St.
San Francisco CA 94104
email: pierre.lin@yipes.com
Marc Lasserre
Riverstone Networks
5200 Great America Parkway
Santa Clara CA 95054
marc@riverstonenet.com
Sunil Khandekar
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Giles Heron
PacketExchange Ltd.
K. Kompella (editor) Expires May 2002 [Page 12]
Internet Draft draft-kompella-ppvpn-vpls-00.txt November 2001
The Truman Brewery
91 Brick Lane
LONDON E1 6QL
United Kingdom
Email: giles@packetexchange.net
Loa Andersson
Utfors AB
Box 525, 169 29 Solna
Sweden
phone: +46 8 5270 5038
email: loa.andersson@utfors.se
Javier Achirica
Telefonica Data
javier.achirica@telefonica-data.com
Vach Kompella
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Email: vkompella@timetra.com
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
yakov@juniper.net
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
kireeti@juniper.net
K. Kompella (editor) Expires May 2002 [Page 13]