Network Working Group Eric C. Rosen
Internet Draft Clarence Filsfils
Expiration Date: January 2002 Cisco Systems, Inc.
Giles Heron Andrew G. Malis
Gone2 Ltd. Vivace Networks, Inc.
Luca Martini Steve Vogelsang
Level 3 Communications, LLC. Laurel Networks, Inc.
July 2001
An Architecture for L2VPNs
draft-ietf-ppvpn-l2vpn-00.txt
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.
Abstract
Service Providers may offer a "Layer 2 VPN Service" over an IP
backbone by provisioning point-to-point "virtual circuits" that run
through IP tunnels. This document discusses the signaling,
encapsulation, and configuration issues that arise. Its purpose is
to provide an architecture which allows different kinds of point-to-
point virtual circuits to be provided through different kinds of IP
tunnels.
Rosen, et al. [Page 1]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
Table of Contents
1 Boilerplate for Sub-IP Area Drafts ..................... 2
2 Introduction ........................................... 3
3 Outline of Architecture ................................ 4
4 Encapsulating .......................................... 6
5 Signaling .............................................. 6
6 Tunneling .............................................. 6
7 Configuration Models ................................... 7
7.1 Brute Force ............................................ 7
7.2 Eliminating Tunnel Configuration ....................... 8
7.3 Single Endpoint Configuration of Emulated VCs .......... 8
7.4 Single Endpoint Configuration of Attachment VCs ........ 9
7.5 Zero-Configuration Attachment VCs ...................... 9
7.6 Auto-discovery of remote CEs ........................... 10
8 References ............................................. 11
9 Authors' Information ................................... 11
1. Boilerplate for Sub-IP Area Drafts
This draft is targeted at the PPVPN WG, as it addresses the following
work item from the PPVPN WG charter:
"The working group is expected to consider at least three
specific approaches including ... port-based VPNs (i.e.,
where the SP provides a Layer 2 interface, such as Frame
Relay or ATM, to the VPN customer, while using IP-based
mechanisms in the provider infrastructure"
The set of related documents may be found in the "References"
section.
Rosen, et al. [Page 2]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
2. Introduction
Enterprises have long built their own wide-area networks by
purchasing wide-area point-to-point data link layer connectivity from
service providers, and then building their own layer 3 infrastructure
on top of that. Originally the data links from the service provider
were leased lines, and the layer 3 overlays were termed "private
networks". Later, virtual circuits of various sorts (X.25, Frame
Relay, ATM) began to replace leased lines, and the layer 3 overlays
were termed "virtual private networks". (Though what makes a leased
line less virtual than an ATM VC is difficult to understand.)
We will refer to these VPNs as "Layer 2 VPNs" because the service
provider providers only a layer 2 interface to its customer, and the
customer is responsible for creating and managing the layer 3
overlay.
Today, layer 2 VPNs are usually offered over a Frame Relay or ATM
infrastructure.
There are still many enterprises that wish to manage their own layer
3 overlays, and many service providers who wish to provide layer 2
interfaces to such customers. However, many of these service
providers would like to replace their Frame Relay or ATM
infrastructures with an IP infrastructure. So it is desirable to
have standard ways of using an IP infrastructure to provide a layer 2
interface to customers. In particular, it is desirable to have
standard ways of using an IP infrastructure to provide virtual
circuits between pairs of customer sites.
The term "Layer 2 VPN" may be somewhat misleading, in that the SP
does not actually provide a VPN to the customer. The SP provides
layer 2 connectivity, and the customer builds his own VPN, using the
provided layer 2 connectivity as one of the building blocks. The
problem is really how to provide the layer 2 connectivity over an IP
backbone, rather than how to provide a network service over an IP
backbone.
Typically a customer will expect a certain amount of bandwidth from
each data link. The customer may build his network using data links
obtained from a variety of providers.
In an L2VPN service, the SP need not know about the customer's
topology, about the customer's policies, or about the customer's
routing. The SP need not even know whether all the point-to-point
links he is providing are used by the customer as part of the same
network, or whether a customer network has point-to-point links from
other providers as well. In essence the customer builds his own
Rosen, et al. [Page 3]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
network, using data link resources obtained from the SP.
Nevertheless, we will continue to use the term "Layer 2 VPN" (L2VPN),
as it is apparently well entrenched in the vernacular, despite its
technical inaccuracy.
We adopt the "Provider Edge" (PE) and "Customer Edge" (CE)
terminology from RFC2547 [RFC2547bis].
Not all L2VPNs are built on top of point-to-point data link
connections. It is possible for an SP to provide an "emulated LAN"
service instead. In this case, the PE device is a LAN switch which
can serve multiple customers, and which can do SA learning and
Spanning Tree on a per-customer basis. Some sort of multicast
technique must be used for transmitting customer LAN multicasts and
unknown DA frames among the PEs which attach to a common customer.
The primary focus of this draft will however be on the provision of
point-to-point data link services. If the CE devices attaching to an
L2VPN's PE devices are LAN switches, the L2VPN may be thought of as a
"Transparent LAN Service", even if the SP provides only point-to-
point data link connections.
The provision of Emulated LAN services over IP backbone networks can
be added at a later date if there is sufficient interest.
3. Outline of Architecture
The general architecture for providing L2VPN services is the
following. A CE devices attaches to a PE device via some sort of
virtual circuit. We will call this the "Attachment VC". To provide
a layer 2 connection between CE1 and CE2, where CE1 attaches to PE1
and CE2 attaches to PE2, an "Emulated VC" must be carried across the
IP backbone from PE1 to PE2. At each of PE1 and PE2, the Emulated VC
is associated with an Attachment VC. In effect, the ordered triple
<CE1-PE1 Attachment VC, PE1-PE2 Emulated VC, PE2-CE2 Attachment VC>
functions as a VC between CE1 and CE2.
The Emulated VC is carried in a "Tunnel" from PE1 to PE2. When there
are multiple Emulated VCs running from PE1 to PE2, a single Tunnel
should be able to carry a large number of Emulated VCs. There should
be no requirement that two Emulated VCs in a common tunnel have the
same CE endpoints. When PE2 removes a packet from a Tunnel, it
associates the packet with an Emulated VC. The association of the
Emulated VC with an Attachment VC determines the CE to which the
packet is sent.
There should be no requirement that all VCs going from PE1 to PE2
Rosen, et al. [Page 4]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
travel in the same tunnel.
If the two Attachment VCs associated with an Emulated VC are of the
same type (e.g., both Frame Relay, both ATM), the Emulated VC may
need to carry some type-specific information with each packet. If
the two Attachment VCs are not of the same type, one or the other end
of the Emulated VC must perform some sort of inter-working function.
It is desired to allow a variety of different tunneling technologies
to be used for the PE-PE Tunnels.
In order to provide this sort of L2VPN architecture in a standard
way, the following need to be standardized:
- Tunneling Protocols. The architecture allows any number of
different tunneling protocols to be used, but each should be
standardized.
* Signaling. The standard for a tunneling protocol will
generally include a signaling protocol, so that tunnels can
be set up dynamically, and tunnel control information can be
passed from one tunnel endpoint to another.
* Encapsulation The standard for a tunneling protocol always
includes a way to encapsulate data packets in the tunnel.
* Multiplexing. Most tunneling protocols allow for multiple
streams to be encapsulated inside a single tunnel. They do
this by supporting a multiplexing field. To support L2VPNs,
each Emulated VC in the tunnel should correspond to a
distinct value of the tunnel multiplexing field. It is
important to note that this multiplexing field belongs to the
tunneling protocol, not to the data packet that is
encapsulated in the tunnel.
- Signaling Protocols for the Emulated VCs. A protocol is needed
to setup and maintain the Emulated VCs that are carried within
the tunnels. This protocol does not set up the tunnels, but only
the Emulated VCs within the tunnels.
Note though that to set up an Emulated VC, one must set up the
multiplexing field value which the tunnel protocol will use when
carrying packets of that Emulated VC. This strongly suggests
that the signaling protocol for setting up an Emulated VC be
specific to the particular tunneling technology that is being
used.
Rosen, et al. [Page 5]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
- Encapsulations for the user data frames. For each kind of layer
2 frame that may be received on an Attachment VC, an
encapsulation must be specified that allows the frame and its
related per-frame control information to be carried within the
Emulated VC.
While not strictly required for standardization, it is also important
to discuss the configuration model for setting up the L2VPN service.
If it turns out that the configuration model can be considerably
simplified through the use of an auto-discovery mechanism, the auto-
discovery mechanism will need to be standardized.
4. Encapsulating
An encapsulation for User Data Frames is proposed in [L2ENCAPS].
Actually, that draft proposes both a tunnel-independent encapsulation
for user data frames, as well as the method for encapsulating the
frames within an MPLS tunnel. We propose to adopt the tunnel-
independent encapsulation specified therein.
5. Signaling
As we stated in the introduction, the signaling used to setup and
maintain the Emulated VCs should depend on the particular tunneling
technology. If MPLS is to be used as the tunneling technology, the
procedures specified in [L2SIG]. That draft proposes to use
extensions to the standard MPLS signaling (LDP) to set up the
multiplexing field (itself an MPLS label) for the Emulated VC, as
well as to setup and pass other control information needed to
maintain the Emulated VC.
If the tunneling technology is L2TP or IPsec, then the signaling
protocols which are native to those tunnel technologies should be
similarly extended.
6. Tunneling
In the case where MPLS is the tunneling technology, [L2SIG] specifies
the way in which frames on one or more Emulated VCs are to be carried
in an MPLS LSP.
Similar drafts are needed for L2TP and IPsec tunnels.
Rosen, et al. [Page 6]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
7. Configuration Models
It can be somewhat unwieldy to configure a large number of point-to-
point VCs. Therefore a number of L2VPN proposals focus on methods of
simplifying the configuration, either by adding additional signaling
mechanisms, or by adding auto-configuration and auto-discovery
mechanisms, or both. The current proposal is to separate the
signaling from any auto-configuration or auto-discovery mechanisms.
Then we can discuss separately the procedures for signaling, given a
particular configuration, and the procedures for creating the that
configuration in the first place.
This approach differs from the approach of RFC2547 for layer 3 VPNs;
there the auto-discovery of VPN sites is combined with the signaling
of MPLS labels for VPN routes. What we propose here is more like the
way auto-discovery is separated from virtual circuit setup in the
Virtual Router (VR) model of layer 3 VPNs. (See, e.g., [AUTO].) In
both the L2VPN case and the VR case, it is necessary to set up data
link connections which go from one PE to another. In the RFC2547
case, there are no cross-network data link connections set up.
Setting up a point-to-point data link connection requires signaling
of the sort specified in [L2SIG], and cannot be properly automated as
a side effect of the auto-discovery procedures.
7.1. Brute Force
In order to provide L2PVN service connecting CE1 and CE2, one
configuration model is the following:
- CE1 must be configured with an Attachment VC to PE1. Call this
A1.
- PE1 must be configured with that same Attachment VC (to CE1).
- CE2 must be configured with an Attachment VC to PE2. Call this
A2.
- PE2 must be configured with that same attachment VC (to CE2).
- PE1 must be configured with an identified Emulated VC to PE2.
- PE2 must be configured with an identified Emulated VC to PE1; the
identifier should be the same at both PEs, and the triple <PE1,
PE2, identifier> must be unique. Call this E.
- PE1 must be configured to associate A1 with E.
- PE2 must be configured to associate A2 with E.
- PE1 must be configured with a tunnel, T1, to PE2, and a tunnel,
T2, from PE2. PE2 must be configured with a tunnel, T1, from
PE1, and a tunnel, T2, to PE1.
Rosen, et al. [Page 7]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
- PE1 must be configured to associate E with T1 and T2.
- PE2 must be configured to associate E with T1 and T2.
Note also that A1, E, and A2 may have specific properties that need
to be configured, e.g., QoS, bandwidth, etc.
7.2. Eliminating Tunnel Configuration
If MPLS is the tunneling technology, and LDP downstream
unsolicited label distribution is used, it is NOT necessary to
configure T1 and T2, or to explicitly associate E with them. The
necessary tunnel exists automatically as long as there is a route
from one PE to the other.
7.3. Single Endpoint Configuration of Emulated VCs
We assumed above that the Emulated VC signaling required that a
particular Emulated VC be configured at both PE endpoints. This
isn't necessarily the case. If the Emulated VC signaling protocol
allows an Emulated VC to be set up based on the configuration of just
a single endpoint, there is no need to configure the other endpoint,
and those steps can be removed.
This enables the configuration model to be simplified to:
- CE1 must be configured with an Attachment VC to PE1. Call this
A1.
- PE1 must be configured with that same Attachment VC (to CE1).
- CE2 must be configured with an Attachment VC to PE2. Call this
A2.
- PE2 must be configured with that same attachment VC (to CE2).
- PE1 must be configured with an identified Emulated VC to PE2.
- PE1 must be configured to associate A1 and A2 with E.
In this case, PE1 must tell PE2 to associate A2 with E. If E has
specified properties, PE1 needs to be configured with these, and must
tell PE2 about them.
It is not completely obvious whether single endpoint configuration of
Emulated VCs is really worthwhile. The provisioning system that
configures the Emulated VCs will generally have to consult the
configuration of both endpoint PEs to determine the availability of
Attachment VCs, to set up QoS for Attachment VCs, etc. In any event,
the signaling procedures of draft- martini-l2circuit-trans-mpls are
easily extended to handle the case of signaling Emulated VCs that are
configured at only one endpoint.
Rosen, et al. [Page 8]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
7.4. Single Endpoint Configuration of Attachment VCs
The need to configure the Attachment VCs on BOTH the CE and the PE
could be eliminated by an appropriate LMI. Then an Attachment VC
could be configured just on the PE, and the PE would use the LMI to
inform the CE. The feasibility of this depends on the particular
technology used for the Attachment VC, and whether such LMI
procedures exist for that technology. If they do, they exist whether
or not an L2VPN service of the sort envisioned here is being offered,
so we need not consider this any further.
We have assumed that the L2VPN service will be a PVC rather than an
SVC service. A model for supporting an SVC service is discussed in
draft-ouldbrahim-bgpgmpls-ovpn. With the SVC model, the need to
configure the Attachment VC (or the Emulated VC) on the PE could be
eliminated. We do not further consider this here.
7.5. Zero-Configuration Attachment VCs
In the "Zero-Configuration of Attachment VCs" model, only the
Emulated VC is configured (at one or both endpoints). The signaling
of the Emulated VC doesn't specify a particular Attachment VC to
associate it with, nor is a particular Attachment VC configured to be
associated with the Emulated VC. Rather, the Emulated VC is simply
associated with an interface at each end. When the Emulated VC is
set up, each endpoint PE creates an Attachment VC on the specified
interface, and some sort of LMI or signaling procedure is used to
inform the CE of this.
Whether this is feasible depends on the particular technology used
for the Attachment VCs. To the extent that an Attachment VC uses a
scarce resource, this is not really feasible. For example, if the CE
and the PE are connected via an ATM or Frame Relay switch, one could
not automatically create an Attachment VC when the Emulated VC is
setup. An Attachment VC in these technologies requires a switch
cross-connect entry, and these scarce resources might not be
available in the absence of an explicit provisioning process. As
another example, if the Attachment VCs must have specific QoS
properties, it might be necessary to do explicit provisioning to
ensure that the necessary QoS characteristics can be met.
On the other hand, if an Attachment VC is nothing more than the value
of some multiplexing field, with no particular QoS characteristics,
and no use of switches between PE and CE, then it might be feasible
to create the Attachment VCs automatically as a side-effect of
setting up an Emulated VC. The procedures for doing this would
depend on the technology used for the Attachment VCs.
Rosen, et al. [Page 9]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
7.6. Auto-discovery of remote CEs
If an L2VPN is to have a hub and spoke topology, some further
simplification of the configuration could be made, as one could
provide some sort of auto-discovery of the hub CE. Then when a new
spoke CE is attached to a PE, the PE would automatically determine
which other PE attaches the corresponding hub CE.
Then when one adds a new spoke CE to the L2VPN, one wouldn't have to
explicitly configure the attached PE with the information about how
to reach the hub. However, a hub and spoke topology is already
simple to configure, and this additional simplification is probably
not worth the additional mechanism.
If an L2VPN is to have a fully meshed topology, simplification of the
configuration could be made. If a PE is attached to a CE of a
particular VPN, it could auto-discover all the other PEs that are
attached to CEs of the same VPN, and could discover for each such PE
the set of CEs in that VPN to which it is attached. This could be
done using the auto-discovery techniques first described in RFC2547
and later extended and generalized in [AUTO]. Once a PE discovers
the complete set of CEs in a given VPN, it can signal an Emulated VC
from itself to each other PE that has a CE attached to the same VPN;
the Emulated VC thus need not be explicitly configured. (This does
presuppose that the Emulated VCs are of uniform characteristics. If
each has some specific QoS property, for example, then this degree of
auto-discovery would be impossible, and more explicit provisioning
would be required.)
If the Attachment VC technology used by that VPN allows for Zero-
Configuration Attachment VCs, a full mesh of point-to-point (CE-CEs)
virtual circuits could be set up, with very little configuration. A
PE would just need to be configured to know which VPN each of its CEs
belongs to.
Whether this sort of auto-discovery is worthwhile is somewhat
dubious, though, since it only really pays off if the L2VPN consists
of a full mesh of point-to-point connections, and this is a very
unusual topology. (Whereas a full mesh of L3 connectivity is the
common case, a full mesh of L2 connections is rather uncommon.) As
discussed in draft-ouldbrahim-bgvpn- auto, additional configuration
information ("colors") could be added to facilitate different
topologies, but once one departs from either the hub and spoke or the
full mesh topology, figuring out how to make the right topology
auto-configure itself quickly becomes more difficult than explicitly
provisioning it.
An auto-discovery scheme of this sort, though combined with a
Rosen, et al. [Page 10]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
particular signaling and encapsulation scheme, is detailed in
[MPLSL2VPN].
8. References
[AUTO] "Using BGP as an Auto-Discovery Mechanism for Network-based
VPNs", Ould-Brahim, et. al., draft-ouldbrahim-bgpvpn-auto-01.txt,
3/01.
[L2ENCAPS] "Encapsulation Methods for Transport of Layer 2 Frames
Over MPLS", Martini, et. al., draft-martini-l2circuit-encap-mpls-
01.txt, 2/01.
[L2SIG] "Transport of Layer 2 Frames Over MPLS", Martini, et. al.,
draft-martini-l2circuit-trans-mpls-05.txt, 2/01.
[MPLSL2VPN] "MPLS-based Layer 2 VPNs", Kompella, et. al., draft-
kompella-mpls-l2vpn-02.txt, 11/00.
[RFC2547bis] "BGP/MPLS VPNs", Rosen et. al. draft-rosen-rfc2547bis-
03.txt, 3/01.
9. Authors' Information
Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: erosen@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Avenue Marcel Thiry, 77
B-1200 Brussels Belgium
E-mail: cfilsfil@cisco.com
Rosen, et al. [Page 11]
Internet Draft draft-ietf-ppvpn-l2vpn-00.txt July 2001
Giles Heron
Gone2 Ltd.
c/o MDP
One Curzon Street
London
W1J 5HD
United Kingdom
e-mail: giles@goneto.net
Andrew G. Malis
Vivace Networks, Inc.
2730 Orchard Parkway
San Jose, CA 95134
Phone: +1 408 383 7223
Email: Andy.Malis@vivacenetworks.com
Luca Martini
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO, 80021
e-mail: luca@level3.net
Steve Vogelsang
Laurel Networks, Inc.
2607 Nicholson Rd.
Sewickley, PA 15143
e-mail: sjv@laurelnetworks.com
Rosen, et al. [Page 12]
