Internet Engineering Task Force CY Lee
INTERNET DRAFT M Higashiyama
July 2002
CE-based Virtual Private LAN
<draft-lee-ce-based-vpl-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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This draft describes how some existing technologies can be leveraged
to realize provider provisioned Virtual Private LAN (VPL) service.
1. Overview
In CE-based VPL, tunnels are setup between sites of a VPL. At a CE
(Customer Edge, See [PPVPN-REQ]),Ethernet traffic from a VPL is
encapsulated in for e.g. a L2TP/GRE/IP tunnel or FR/ATM VC and
transported over the (IP/FR/ATM) network to another CE of the VPL.
The receiving CE decapsulates the Ethernet frame and forward the
frame to the destination node in the VPL.
In this initial version of the draft, the focus is on using L2TP
[L2TP, L2TPv3] tunnels over an IP PSN (Packet Switching Network)
Other tunneling protocols shall be considered later.
The following two figures [adapted from [LT2P-ETH]] describe the
Expires January 2003 [Page 1]
Internet Draft CE-based VPL July 2002
reference models to support VPL services.
Emulated Service
(Broadcast Domain/"LAN", within dotted lines)
..................................
Native . . Native
Ethernet . . Ethernet
or . |<-- PSN Tunnel-->| . or
VLAN . . VLAN
Service . +----+ +----+ . Service
| . |CE1 | | CE2| . |
Customer-------.--| |=================| |-.------- Customer
LAN | . | | | | . | LAN
Site 1 | . +----+ +----+ . | Site 2
. \\ // .
. \\ // .
. \\ // .
. PSN \\ // PSN .
. Tunnel \\ +----+ // Tunnel.
. \\|CE3 |// .
. \| |/ .
. +----+ .
. | .
..................................
|
|
Native Ethernet or
VLAN Service
|
|
Customer LAN
Site 3
|
|
Customer ----------------|----------------Customer
LAN Site 1 | LAN Site 2
|
|----------------Customer
| LAN Site 3
Fig 1 Emulated Ethernet Segment
Expires January 2003 [Page 2]
Internet Draft CE-based VPL July 2002
+-------------+ +-------------+
| Emulated | | Emulated |
| Ethernet | | Ethernet |
| (including | Emulated Service | (including |
| VLAN) |<==============================>| VLAN) |
| Services | | Services |
+-------------+ Ethernet Pseudo Wire +-------------+
|Encapsulation|<==============================>|Encapsulation|
|& Bridging | |& Bridging |
+-------------+ +-------------+
| | PSN Tunnel | |
| IP |<==============================>| IP |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| PSN |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+========/ |===+
\ /
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Fig 3: VPL Protocol Stack Reference Model
2. Leveraging existing solutions - CE-based VPL
CE-based VPL over different types of tunneling technologies has been
used for a number of years now, and could be viewed as a proven
technology. A network user provisions the required tunnels (or
circuits) at a CE to remote CE(s) and the CEs bridge Ethernet traffic
over the tunnels.
Providers already has the management infrastructure to manage and
configure remote CEs, although automated discovery of configuration
parameters can be introduced where possible to reduce manual
configuration of CEs. Should CE-based VPL approach be leveraged by
providers to offer VPL service to customers?
2.1 CE-based VPL features
* connectivity states incurred only in CEs, no VPL connectivity
states incurred in PEs (Provider Edge Equipment) or Ps (Provider's
Expires January 2003 [Page 3]
Internet Draft CE-based VPL July 2002
network equipment) [See PPVPN-REQ].
* CEs belonging to the same VPL learn, store, manage VPL forwarding
information and bridges traffic within the VPL, PEs do not have to
learn MAC addresses from different VPLs, hence this approach scales
for large number of VPLs and total MAC addresses in a network. The
provider need not set limits on the number of MAC addresses in each
VPL/CE at PEs.
* bridging within a VPL does not affect other VPLs (or customers). A
CE bridge which is not functioning correctly will only affect a VPL.
In contrast, if bridging is also performed at PEs, a malfunctioning
CE may cause network instability and affect other VPLs as well. Hence
a CE-based VPL would be operationally stabler.
* allow routers of a VPN to peer using a VPL, hence routing overlay
is invisible to routers and appear as a broadcast domain instead.
This simplifies VPN router configuration for the customer.
* CEs may be located intra-domain or inter-domain as long as CEs have
IP reachability to each other. CEs in different metro network or
rings can send VPL traffic to each other without resorting to
Stackable VLAN as long as there is IP reachability in the network.
(Note: This does not imply routing is required e.g. the CEs may all
be in the same subnet in the provider's network)
* optimal bridging or forwarding of traffic from one CE to another CE
within PSN, but VPL traffic is not bridged optimally unless full
meshed of IP tunnels are used. Network based VPL (where bridging is
performed in the network) is more optimal in forwarding traffic
* In a network based VPL, as the number of customers/VPLS and total
MAC addresses grow in a provider's network, existing devices in the
network will need to be upgraded or replace by new devices. A CE-
based VPL approach scales as the number of VPLs and total number of
MAC addresses in VPLs grows and allows CEs in different metro network
to be interconnected seamlessly.
* Multiple virtual tunnels to other CE sites can be automatically
configured on CEs if a tunnel endpoint information discovery
mechanism is used.
* CE-based VPL can be offered over an existing VLAN (802.1q) network
and co-exist with existing VLANs
* new VPLs can be added transparently in an IP/MPLS network, without
having to upgrade PEs with bridging functions
Expires January 2003 [Page 4]
Internet Draft CE-based VPL July 2002
* existing customers' Ethernet switches can be connected to a
provider provisioned CE-based VPL.
3. PSN Tunnels
A CE setup PSN tunnels (L2TP/GRE/IPSec) to other remote CE sites.
CEs may be configured with or auto-discover the addresses of remote
CE sites. See Section on "Tunnel Endpoint Information".
In this initial version of the draft, only L2TP tunnels shall be
considered.
4. Ethernet over L2TP
[L2TP] was originally specified for tunneling PPP sessions. [L2TPv3]
The base L2TP protocol which does not include the PPP specific
mechanisms is now being specified in [L2TPv3]. [L2TPv3] provides new
extensions for tunneling other L2 protocols such as Ethernet, ATM and
Frame Relay, but the specific L2TP extensions required for each L2
technology are being specified in other documents e.g. [L2TP-FR],
[L2TP-ETH].
4.1 Alternatives
Two different variants of providing VPL service are identified: i)
using [BCP], tunneling over PPP and [L2TP] is described in [EOL2TP]
as voluntary tunneling. This approach does not require any change in
[L2TP] or [BCP] specifications. ii) directly over L2TPv3. The
changes required to tunnel point to point Ethernet pseudo wire (from
one PE to another PE) directly over L2TP are being specified in
[L2TP-ETH]. [Lassere-Vkompella] describes point to multipoint
Ethernet over MPLS, where the bridging of VPL traffic is performed at
the PEs.
This rest of Section 4 describes how L2TP tunneling in [L2TP-ETH] can
be used to tunnel Ethernet over L2TP from one CE to another CE (where
the pseudo wire endpoints are CEs), how bridging is performed at CEs
and how multipoint Ethernet pseudo wire (or a virtual broadcast
domain/LAN service) can be realized.
Section 6 describes how traffic forwarding over a VPL can be improved
for both (i) and (ii).
4.1.1 Establishing L2TPv3 session
A CE establishes a L2TPv3 control connection and session to remote
sites of the VPL. [See section on "Tunnel Endpoint Information"] The
L2TPv3 parameters defined in [L2TP-ETH] for e.g. pseudo wire type,
Expires January 2003 [Page 5]
Internet Draft CE-based VPL July 2002
session id, speed and MTU are signaled during the session setup.
A virtual interface is created for every L2TP session setup to a
remote site.
4.1.1.1 Tunnel Endpoint Authentication
If a CE authenticate the remote CE using L2TP, a Challenge AVP is
included in the L2TP control connection setup message, as described
in [L2TPv3]. If the expected response received from a CE does not
match, the establishment of the control connection MUST be
disallowed. A CHAP-like [RFC1994] authentication is used at each
CE. To use L2TP tunnel authentication, a single shared secret MUST
exist between the two CEs. [See section on "Tunnel Endpoint
Information" on shared key configuration].
L2TP (Layer Two Tunneling Protocol) may use IPsec for tunnel
authentication as described in [L2TP-IPSEC] instead.
4.1.2 Bridging
A CE learns MAC addresses from the customer facing ports and the
virtual interfaces (or the tunnels to remote CE sites). When a new
MAC address is learned, the MAC address is associated with the
virtual interface or ports where the frame arrives. When a frame with
the cached MAC address is received, the CE knows which virtual
interface or port to forward the frame to. When a frame with a new
MAC address is received, a CE floods the frame to all other ports or
virtual interfaces, except the interface where the frame is received
from. To optimize forwarding of traffic over a VPL see the next
section.
The learning, bridging, filtering and forwarding procedures are as
defined in [802.1d] and [802.1q], except that the ports on a switch
in this case can be a virtual interface as well as a physical port.
5. Optimizing bridging over a VPL
To optimize the forwarding of traffic in a VPL, a full mesh of
tunnels may be setup among CE sites. Bridging is modified such that
traffic is not flooded to interfaces participating in the fully-
meshed VPL connectivity. In this case, since each CE has a direct
tunnel to other CEs, traffic arriving at a CE need not be forwarded
to other CEs. Spanning Tree should be turned off if CEs are fully-
meshed.
The states in setting up a full meshed of tunnels (over an IP
network) are only incurred at CEs. [Note: If the number of sites of
Expires January 2003 [Page 6]
Internet Draft CE-based VPL July 2002
a VPL is very large, the VPL should be split into multiple
subnets/VPLs instead].
6. Tunnel Endpoints Information
The tunnel endpoints information may be pre-configured or remotely
provisioned or, a mechanism to discover and distribute the tunnel
endpoints information may be used or a mechanism where tunnel
endponts information are retrieved from a server (e.g. RADIUS) may be
used.
To avoid having to provision deployed CEs, a mechanism to auto
discover and distribute VPL site information is useful. [RADIUS],
[VPLS-DNS] and [CE-AUTOCONFIG] are examples of mechanisms that may be
used for this purpose. If previously the provisioning of a full-
meshed of CEs is performed directly on the CEs, an auto discovery
mechanism reduces the provisioning required for a VPL to O(n), where
n is the number of sites in a VPL.
More detailed management or troubleshooting of CEs may be performed
over existing infrastructure used to manage remote CEs.
7. Fault Detection
The procedures for PW monitoring and fault detection described in
[L2TP-ETH] may be used to monitor the virtual interfaces or L2TP
sessions. Any alarms generated may be sent to the NOC via e.g. the
existing infrastructure used to manage remote CEs.
8. Acknowledgment
The authors would like to thank Jeremy deClercq and Jeanne DeJaegher
for their helpful comments on this draft. The draft benefited from
discussions with Sasha Cirkovic, Jeff Smith, Roy Nighswander, Neil
Harrison, Alexis Berthillier, Dean Welsh and Arnold Jansen.
Normative References
[802.1D] IEEE, "ISO/IEC 15802-3:1998,(802.1D, 1998 Edition),
Information technology --Telecommunications and information exchange
between systems --IEEE standard for local and metropolitan area
networks --Common specifications-Media access control (MAC) Bridges",
June, 1998.
[802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged Local Area Networks",
1998 .
Expires January 2003 [Page 7]
Internet Draft CE-based VPL July 2002
[802.3] IEEE, "ISO/IEC 8802-3: 2000 (E), Information
technology--Telecommunications and information exchange between
systems --Local and metropolitan area networks --Specific
requirements --Part 3: Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical Layer Specifications",
2000.
[BCP] Mitsuru H. and Baker, "PPP Bridging Control Protocol (BCP)",
RFC 2878, July 2000.
[L2TP] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G., Zorn,
G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661
August 1999
[L2TPv3] Lau, J., Townsley, M., Valencia, A., Zorn, G., Goyret, I.,
Pall, G., Rubens, A., Palter, B., "Layer Two Tunneling Protocol
"L2TP"", (draft-ietf-l2tpext- l2tp-base-01.txt), work in progress,
July 2001.
[L2TP-IPSEC] RFC 3193, B. Patel,B. Aboba,W. Dixon, G. Zorn, S. Booth
"Securing L2TP using IPSec"
[L2TP-ETH] So, et al., Ethernet Pseudo Wire Emulation Edge-to-Edge
(PWE3). draft-so-pwe3-ethernet-01.txt, March 2002.
Informational References
[EOL2TP] M. Higashiyama, "Ethernet Over L2TP", (draft-higashiyama-
eol2tp-01.txt), November 2001
[PPVPN-REQ] M. Carugi,D. McDysan, L. Fang, F. Johansson, Ananth
Nagarajan, J. Sumimoto, R. Wilder, "Service requirements for Layer 3
Provider Provisioned Virtual Private Networks" (draft-ietf-ppvpn-
requirements-04.txt)
[CEVPN] De Clercq J., et al., "Provider Provisioned CE-based Virtual
Private Networks using IPsec", draft-ietf-ppvpn-ce-based-01.txt, work
in progress.
[Kompella] Kompella, K., Leelanivas, M., Vohra, Q., Bonica, R., Metz,
E., Ould-Brahim, H., Achirica, J., Z., "MPLS-based Layer 2 VPNs",
(draft-kompella- ppvpn-l2vpn-00.txt), work in progress, July 2001.
[Martini-encap] Martini, L., El-Aawar, N., Tappan, D., Rosen, E.,
Jayakumar, J., Vlachos, D., Liljenstolpe, C., Heron, G., Kompella,
K., Vogelsang, S., Shirron, J., Smith, T., Radoaca, V., Malis, A.,
Sirkay, V., Cooper, D., "Encapsulation Methods for Transport of
Layer 2 Frames Over IP and MPLS Networks", (draft-martini- l2circuit-
Expires January 2003 [Page 8]
Internet Draft CE-based VPL July 2002
encap-mpls-03.txt), work in progress, July 2001.
[PWE3-frame] Pate, P., Xiao, X., So, T., Malis, A., Nadeau, T.,
White, C., Kompella, K., Johnson, T., "Framework for Pseudo Wire
Emulation Edge-to-Edge (PWE3)" (draft- pate-pwe3-framework-02.txt),
work in progress, July 2001.
[Laserre-Vkompella] Lasserre, M, Kompella, V, et al, "Virtual Private
LAN Services over MPLS" draft-lasserre-vkompella-ppvpn-vpls-01.txt,
March 2002
[VPLS-DNS] Heinanen, "DNS/LDP Based VPLS". draft-heinanen-dns-ldp-
vpls-00.txt, January 2002.
[CE-AUTOCONFIG] CY Lee, "CE Auto-Configuration", (draft-lee-ppvpn-ce-
auto-config-01.txt), work in progress, July 2002
[RADIUS] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial in User Service (RADIUS)", RFC 2865, June 2000.
Authors' Information
Cheng-Yin Lee Cheng-Yin.Lee@alcatel.com
Mitsuru Higashiyama Mitsuru.Higashiyama@yy.anritsu.co.jp
Expires January 2003 [Page 9]